*Backwards Compatibility / Support: *
This is definitely something we need to cover.

I'm guessing the obvious choice would be to continue the 2.9.X versions
under sharpen, maintain the current api thats has java idioms so that people
can continue to use it, release patches, ensure stability with the current
community. This would be important for people who have built products on top
of lucene.net.

The 3.0 version should probably match java in terms of breaking the api due
to the language changes or maybe even a separate project inside:
lucene.netredux (for lack of a better term at the moment).
*
*
--
Michael Herndon

Maybe we could just bug-fix support the current 2.9.2 codebase unless people
really need something in 2.9.x

I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
version.

I'd like to throw another idea into the mix which is perhaps the idiomatic
version could be created by an automated refactoring of the line-by-line. It
might be additional upfront work but might make it easier for future changes
from java lucene to be propagated down.

Alex

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
Michael Herndon
Sent: Friday, December 31, 2010 1:28 PM
To: [EMAIL PROTECTED]
Subject: Proposal Stage: Backwards Compatibility / Support

*Backwards Compatibility / Support: *
This is definitely something we need to cover.

I'm guessing the obvious choice would be to continue the 2.9.X versions
under sharpen, maintain the current api thats has java idioms so that people
can continue to use it, release patches, ensure stability with the current
community. This would be important for people who have built products on top
of lucene.net.

The 3.0 version should probably match java in terms of breaking the api due
to the language changes or maybe even a separate project inside:
lucene.netredux (for lack of a better term at the moment).
*
*
--
Michael Herndon

We are inheriting the outstanding issues facing the Lucene.Net project.

This includes remaining committed to providing a line-by-line port
that stays in sync with the Java Lucene releases.

The project is currently extremely behind schedule on this. The 2.9.2
code base, which is widely used and thus a fairly well received build,
has never been formally packaged as a release (i.e. binary builds,
etc). This is the first order of business to take care of (in terms of
code).

After that we need to evaluate weather or not to create releases to
match all subsequent releases made by the Java Lucene project.

Those releases are:
- 3.0.0
- 3.0.1
- 2.9.3
- 3.0.2
- 2.9.4
- 3.0.3

In the interest of time, we could skip some of the intermediate
releases and just get in sync at 2.9.4 and 3.0.3 releases.

The 3.0.X ports should be 100% Sharpen conversions and post-processing
scripts. Once written, anyone should be able to repeat the process of
pulling down the appropriate Java Lucene SVN revision, executing the
porting scripts, and building the resulting .NET code, yield a valid
3.0.X release with a 1:1 matching API.

This is something we will need to continue being able to do for every
subsequent Java Lucene release.

This aspect of our development should be completely separate from our
refactoring/re-imagining of a more .NET-like API. They need to be
separate development branches, and possibly even completely different
implementations. We will attempt to reuse as much of the automated
port code as we can, with the understanding that the goal of the
secondary branch is to make a high-quality .NET implementation of
Lucene, rather than a API compatible implementation.

Thanks,
Troy

On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
> Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> really need something in 2.9.x
>
> I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> version.
>
> I'd like to throw another idea into the mix which is perhaps the idiomatic
> version could be created by an automated refactoring of the line-by-line. It
> might be additional upfront work but might make it easier for future changes
> from java lucene to be propagated down.
>
> Alex
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Michael Herndon
> Sent: Friday, December 31, 2010 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Proposal Stage: Backwards Compatibility / Support
>
> *Backwards Compatibility / Support: *
> This is definitely something we need to cover.
>
> I'm guessing the obvious choice would be to continue the 2.9.X versions
> under sharpen, maintain the current api thats has java idioms so that people
> can continue to use it, release patches, ensure stability with the current
> community. This would be important for people who have built products on top
> of lucene.net.
>
> The 3.0 version should probably match java in terms of breaking the api due
> to the language changes or maybe even a separate project inside:
> lucene.netredux (for lack of a better term at the moment).
>
>
> *
> *
> --
> Michael Herndon
>
>

> The 3.0.X ports should be 100% Sharpen
Why?
What about other alternatives?

Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )

DIGY

-----Original Message-----
From: Troy Howard [mailto:[EMAIL PROTECTED]]
Sent: Saturday, January 01, 2011 1:58 AM
To: [EMAIL PROTECTED]
Subject: Re: Proposal Stage: Backwards Compatibility / Support

We are inheriting the outstanding issues facing the Lucene.Net project.

This includes remaining committed to providing a line-by-line port
that stays in sync with the Java Lucene releases.

The project is currently extremely behind schedule on this. The 2.9.2
code base, which is widely used and thus a fairly well received build,
has never been formally packaged as a release (i.e. binary builds,
etc). This is the first order of business to take care of (in terms of
code).

After that we need to evaluate weather or not to create releases to
match all subsequent releases made by the Java Lucene project.

Those releases are:
- 3.0.0
- 3.0.1
- 2.9.3
- 3.0.2
- 2.9.4
- 3.0.3

In the interest of time, we could skip some of the intermediate
releases and just get in sync at 2.9.4 and 3.0.3 releases.

The 3.0.X ports should be 100% Sharpen conversions and post-processing
scripts. Once written, anyone should be able to repeat the process of
pulling down the appropriate Java Lucene SVN revision, executing the
porting scripts, and building the resulting .NET code, yield a valid
3.0.X release with a 1:1 matching API.

This is something we will need to continue being able to do for every
subsequent Java Lucene release.

This aspect of our development should be completely separate from our
refactoring/re-imagining of a more .NET-like API. They need to be
separate development branches, and possibly even completely different
implementations. We will attempt to reuse as much of the automated
port code as we can, with the understanding that the goal of the
secondary branch is to make a high-quality .NET implementation of
Lucene, rather than a API compatible implementation.

Thanks,
Troy

On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
> Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> really need something in 2.9.x
>
> I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> version.
>
> I'd like to throw another idea into the mix which is perhaps the idiomatic
> version could be created by an automated refactoring of the line-by-line. It
> might be additional upfront work but might make it easier for future changes
> from java lucene to be propagated down.
>
> Alex
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> Michael Herndon
> Sent: Friday, December 31, 2010 1:28 PM
> To: [EMAIL PROTECTED]
> Subject: Proposal Stage: Backwards Compatibility / Support
>
> *Backwards Compatibility / Support: *
> This is definitely something we need to cover.
>
> I'm guessing the obvious choice would be to continue the 2.9.X versions
> under sharpen, maintain the current api thats has java idioms so that people
> can continue to use it, release patches, ensure stability with the current
> community. This would be important for people who have built products on top
> of lucene.net.
>
> The 3.0 version should probably match java in terms of breaking the api due
> to the language changes or maybe even a separate project inside:
> lucene.netredux (for lack of a better term at the moment).
>
>
> *
> *
> --
> Michael Herndon
>
>

I think the 100% Sharpen is more to mean, it should be 100% automatic conversion including pre/post processing scripts so that future translations can be quick, easy, and as error free as possible. If you replace 100% Sharpen with 100% Java 2 CSharp Translator I think Troy's intent stands.
As for Sharpen specifically - I think it comes from when we were trying back in mid November to get it up and going, it was the only free option we could find. The eclipse plugin I haven't seen before, but should definitely be evaluated. As for Tangibles - I actually like their software (I've used their VB.Net -> C# for a few projects), but I couldn't get a copy for testing purposes - and unless we can get a free licenses for the project, I don't like the idea of requiring a piece of not free software as part of our conversion process.
~P
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 19:03:25 +0200
>
> > The 3.0.X ports should be 100% Sharpen
> Why?
> What about other alternatives?
>
> Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>
> DIGY
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 01, 2011 1:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
>
> We are inheriting the outstanding issues facing the Lucene.Net project.
>
> This includes remaining committed to providing a line-by-line port
> that stays in sync with the Java Lucene releases.
>
> The project is currently extremely behind schedule on this. The 2.9.2
> code base, which is widely used and thus a fairly well received build,
> has never been formally packaged as a release (i.e. binary builds,
> etc). This is the first order of business to take care of (in terms of
> code).
>
> After that we need to evaluate weather or not to create releases to
> match all subsequent releases made by the Java Lucene project.
>
> Those releases are:
> - 3.0.0
> - 3.0.1
> - 2.9.3
> - 3.0.2
> - 2.9.4
> - 3.0.3
>
> In the interest of time, we could skip some of the intermediate
> releases and just get in sync at 2.9.4 and 3.0.3 releases.
>
> The 3.0.X ports should be 100% Sharpen conversions and post-processing
> scripts. Once written, anyone should be able to repeat the process of
> pulling down the appropriate Java Lucene SVN revision, executing the
> porting scripts, and building the resulting .NET code, yield a valid
> 3.0.X release with a 1:1 matching API.
>
> This is something we will need to continue being able to do for every
> subsequent Java Lucene release.
>
> This aspect of our development should be completely separate from our
> refactoring/re-imagining of a more .NET-like API. They need to be
> separate development branches, and possibly even completely different
> implementations. We will attempt to reuse as much of the automated
> port code as we can, with the understanding that the goal of the
> secondary branch is to make a high-quality .NET implementation of
> Lucene, rather than a API compatible implementation.
>
> Thanks,
> Troy
>
>
>
> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
> > Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> > really need something in 2.9.x
> >
> > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > version.
> >
> > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > version could be created by an automated refactoring of the line-by-line. It
> > might be additional upfront work but might make it easier for future changes
> > from java lucene to be propagated down.
> >
> > Alex
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> > Michael Herndon
> > Sent: Friday, December 31, 2010 1:28 PM
     

I think Prescott explained it very well. I should not have specified a
tool. Any tool that enables a 100% automated conversion will meet our
needs.

What we need is a methodology for conversion which meets these criteria:
- Automated, Repeatable, and Well Documented (e.g. a script or build
task with minimal human involvement)
- Based on free, open source tools
- Performs a reasonable and high quality conversion that presents a
1:1 API between Java/C# and the same functionality and performance
I liked the idea of using Sharpen because it's FOSS and because it
allows you to customize your conversions. It's the only system I've
found that allows you to modify it's behaviour. Most of the other
conversion tools just crank through the code "doing their best" and
leave you will a partial conversion which must then be manually
cleaned up. I'd like to have a tool which allows us to define custom
conversion so that at the end of the automated (but custom configured)
process, you have no need to do any additional manual work. I think
Sharpen might enable that.

That said, I think we should explore other options. One possibility is
for us to ask Tangible to donate licenses for their tool. Many
companies will donate licenses to open source projects. That leaves
the question: Does the Tangible tool meet the above criteria even if
it was freely available to us?

Another possibility is to develop a customized conversion tool. This
isn't quite as hard as it may seem. There are existing tools (such as
ANTLR) that can take Java source and parse it into an AST (Abstract
Syntax Tree). Then, we can convert the Java AST to a C# AST, and
compile using the .NET BCL. Writing a *generalized* converter for that
purpose would be difficult. Writing one that just supports the needs
of our project would be less difficult. We could also incorporate a
facility to inject custom conversion logic into the AST->AST
conversion logic. Much of it could be generalized, and where it didn't
have appropriate conversion logic, or where we wanted to override
false-positive logic, we could specify a injectable piece of
conversion logic that we manually coded.

That may seem like a lofty plan, but  it could work, and might be the
best solution in the end. We could start a separate project just for
that, and perhaps start working towards a system that could be used
for all the Java projects at Apache, to generate customized
conversions to C#.

I recall finding a open source project that was similar to the AST
level conversion process I was just describing, but at the moment I
can't remember the name of the project or find it in Google. :(

Here's a similar project that uses this methodology to go from Java to Scala:

http://code.google.com/p/jatran/

It was designed to be extended to work with numerous output languages,
so that could be a good starting point. It only supports Java 5 (1.5)
but that should be sufficient to port Lucene.

Anyhow, those are my thoughts at the moment.

Thanks,
Troy

On Sun, Jan 2, 2011 at 1:35 PM, Prescott Nasser <[EMAIL PROTECTED]> wrote:
>
> I think the 100% Sharpen is more to mean, it should be 100% automatic conversion including pre/post processing scripts so that future translations can be quick, easy, and as error free as possible. If you replace 100% Sharpen with 100% Java 2 CSharp Translator I think Troy's intent stands.
> As for Sharpen specifically - I think it comes from when we were trying back in mid November to get it up and going, it was the only free option we could find. The eclipse plugin I haven't seen before, but should definitely be evaluated. As for Tangibles - I actually like their software (I've used their VB.Net -> C# for a few projects), but I couldn't get a copy for testing purposes - and unless we can get a free licenses for the project, I don't like the idea of requiring a piece of not free software as part of our conversion process.
> ~P
>
>
>
>
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]

I'm pretty sure Tangible does provide free licenses to open source projects - but they must be well and established, which I believe Lucene qualifies as.
Regarding the methodology - I think based on free open source tools isn't required, as long as it's free to us, it should suit our purposes - why must it be open source if it fits our needs? (Tangible isn't open source).
Customizing the conversions is definitely beneficial, but if pre/post processing scripts achieve similar results to the actual customizing of the conversion process, I don't see any difference.
Regarding the non build-able solutions - Sharpen as is won't give us a build-able solution either - it will require us to tweak it, as would any option we choose. The question really is do we create scripts that run independently of the conversion process or do we customize the actual conversion process. I don't think there is really much distinction in which we chose.
Rolling our own conversion tool would be cool, but it's definitely outside my comfort zone, and my limited knowledge leads me to believe it would be more work than other options and would take away from the main goal of the project. This is more my own feelings, not necessarily grounded in reality.
> From: [EMAIL PROTECTED]
> Date: Sun, 2 Jan 2011 15:15:39 -0800
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
> To: [EMAIL PROTECTED]
>
> I think Prescott explained it very well. I should not have specified a
> tool. Any tool that enables a 100% automated conversion will meet our
> needs.
>
> What we need is a methodology for conversion which meets these criteria:
> - Automated, Repeatable, and Well Documented (e.g. a script or build
> task with minimal human involvement)
> - Based on free, open source tools
> - Performs a reasonable and high quality conversion that presents a
> 1:1 API between Java/C# and the same functionality and performance
>
>
> I liked the idea of using Sharpen because it's FOSS and because it
> allows you to customize your conversions. It's the only system I've
> found that allows you to modify it's behaviour. Most of the other
> conversion tools just crank through the code "doing their best" and
> leave you will a partial conversion which must then be manually
> cleaned up. I'd like to have a tool which allows us to define custom
> conversion so that at the end of the automated (but custom configured)
> process, you have no need to do any additional manual work. I think
> Sharpen might enable that.
>
> That said, I think we should explore other options. One possibility is
> for us to ask Tangible to donate licenses for their tool. Many
> companies will donate licenses to open source projects. That leaves
> the question: Does the Tangible tool meet the above criteria even if
> it was freely available to us?
>
> Another possibility is to develop a customized conversion tool. This
> isn't quite as hard as it may seem. There are existing tools (such as
> ANTLR) that can take Java source and parse it into an AST (Abstract
> Syntax Tree). Then, we can convert the Java AST to a C# AST, and
> compile using the .NET BCL. Writing a *generalized* converter for that
> purpose would be difficult. Writing one that just supports the needs
> of our project would be less difficult. We could also incorporate a
> facility to inject custom conversion logic into the AST->AST
> conversion logic. Much of it could be generalized, and where it didn't
> have appropriate conversion logic, or where we wanted to override
> false-positive logic, we could specify a injectable piece of
> conversion logic that we manually coded.
>
> That may seem like a lofty plan, but  it could work, and might be the
> best solution in the end. We could start a separate project just for
> that, and perhaps start working towards a system that could be used
> for all the Java projects at Apache, to generate customized
> conversions to C#.
>
> I recall finding a open source project that was similar to the AST
     

Also, was there any pre/post processing involved in these files? Was it manual / scripts etc? Just trying to get a feel for the work involved.
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 19:03:25 +0200
>
> > The 3.0.X ports should be 100% Sharpen
> Why?
> What about other alternatives?
>
> Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>
> DIGY
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 01, 2011 1:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
>
> We are inheriting the outstanding issues facing the Lucene.Net project.
>
> This includes remaining committed to providing a line-by-line port
> that stays in sync with the Java Lucene releases.
>
> The project is currently extremely behind schedule on this. The 2.9.2
> code base, which is widely used and thus a fairly well received build,
> has never been formally packaged as a release (i.e. binary builds,
> etc). This is the first order of business to take care of (in terms of
> code).
>
> After that we need to evaluate weather or not to create releases to
> match all subsequent releases made by the Java Lucene project.
>
> Those releases are:
> - 3.0.0
> - 3.0.1
> - 2.9.3
> - 3.0.2
> - 2.9.4
> - 3.0.3
>
> In the interest of time, we could skip some of the intermediate
> releases and just get in sync at 2.9.4 and 3.0.3 releases.
>
> The 3.0.X ports should be 100% Sharpen conversions and post-processing
> scripts. Once written, anyone should be able to repeat the process of
> pulling down the appropriate Java Lucene SVN revision, executing the
> porting scripts, and building the resulting .NET code, yield a valid
> 3.0.X release with a 1:1 matching API.
>
> This is something we will need to continue being able to do for every
> subsequent Java Lucene release.
>
> This aspect of our development should be completely separate from our
> refactoring/re-imagining of a more .NET-like API. They need to be
> separate development branches, and possibly even completely different
> implementations. We will attempt to reuse as much of the automated
> port code as we can, with the understanding that the goal of the
> secondary branch is to make a high-quality .NET implementation of
> Lucene, rather than a API compatible implementation.
>
> Thanks,
> Troy
>
>
>
> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
> > Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> > really need something in 2.9.x
> >
> > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > version.
> >
> > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > version could be created by an automated refactoring of the line-by-line. It
> > might be additional upfront work but might make it easier for future changes
> > from java lucene to be propagated down.
> >
> > Alex
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> > Michael Herndon
> > Sent: Friday, December 31, 2010 1:28 PM
> > To: [EMAIL PROTECTED]
> > Subject: Proposal Stage: Backwards Compatibility / Support
> >
> > *Backwards Compatibility / Support: *
> > This is definitely something we need to cover.
> >
> > I'm guessing the obvious choice would be to continue the 2.9.X versions
> > under sharpen, maintain the current api thats has java idioms so that people
> > can continue to use it, release patches, ensure stability with the current
> > community. This would be important for people who have built products on top
> > of lucene.net.
> >
> > The 3.0 version should probably match java in terms of breaking the api due
> > to the language changes or maybe even a separate project inside:
     

The complicated part about having a release for release is that there might
be certain bugs that are only on our side, thus paying attention to the
build interval becomes important for people.

i.e.

build 3.0.0.234 = 3.0.0 release
build 3.0.0.446 = 3.0.0 hotfix

Is there a better way of handling or noting these type of releases?

Is there any benefit of doing all of 3.0.x & 2.9.x releases versus starting
with the latest of each branch and moving forward from there?

Also are we going to ensure mono support?
On Sun, Jan 2, 2011 at 4:36 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Also, was there any pre/post processing involved in these files? Was it
> manual / scripts etc? Just trying to get a feel for the work involved.
>
>
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> >
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> >
> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> >
> > DIGY
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> >
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> >
> > The project is currently extremely behind schedule on this. The 2.9.2
> > code base, which is widely used and thus a fairly well received build,
> > has never been formally packaged as a release (i.e. binary builds,
> > etc). This is the first order of business to take care of (in terms of
> > code).
> >
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> >
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> >
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> >
> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
> > scripts. Once written, anyone should be able to repeat the process of
> > pulling down the appropriate Java Lucene SVN revision, executing the
> > porting scripts, and building the resulting .NET code, yield a valid
> > 3.0.X release with a 1:1 matching API.
> >
> > This is something we will need to continue being able to do for every
> > subsequent Java Lucene release.
> >
> > This aspect of our development should be completely separate from our
> > refactoring/re-imagining of a more .NET-like API. They need to be
> > separate development branches, and possibly even completely different
> > implementations. We will attempt to reuse as much of the automated
> > port code as we can, with the understanding that the goal of the
> > secondary branch is to make a high-quality .NET implementation of
> > Lucene, rather than a API compatible implementation.
> >
> > Thanks,
> > Troy
> >
> >
> >
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]>
> wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless
> people
> > > really need something in 2.9.x
> > >
> > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > > version.
> > >
> > > I'd like to throw another idea into the mix which is perhaps the
> idiomatic
> > > version could be created by an automated refactoring of the
> line-by-line. It
> > > might be additional upfront work but might make it easier for future
> changes
> > > from java lucene to be propagated down.
> > >
> > > Alex
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf

Michael Herndon
Senior Developer ([EMAIL PROTECTED])
804.767.0083

[connect online]
http://www.opensourceconnections.com
http://www.amptools.net
http://www.linkedin.com/pub/michael-herndon/4/893/23
http://www.facebook.com/amptools.net
http://www.twitter.com/amptools-net

For bug fix releases that need to come after a main release but can't
increment the version number, then a build number is ok, but generally
I prefer to just refer to them by name and revision number.

eg:

build 3.0.0.234 = 3.0.0 RTM (rev 100)
build 3.0.0.446 = 3.0.0 HotFix1 (rev 123)

etc...

This is because build numbers can be rather arbitrary, and doesn't
help much when you're working with the library from code and not
binaries. Knowing what SVN revision a given release is, is more
useful.

Regarding skipping the intermediate Java releases... The only benefit
to matching each of those is if someone were to need to port a Java
application that relied on an intermediate version to C#, and didn't
want to do the work of upgrading to a newer version (assuming a lack
of backward compatibility for their use case). Then they would need an
exact matching version in C#.

This seems like an unlikely use case, and it's my opinion we should
just skip the intermediate releases and make our next release after
2.9.2 match the latest Java releases (eg. 2.9.4 and 3.0.3).

While there's a sense of urgency about getting a 3.X release out for
.NET, I think the community would be better served by getting the
2.9.4 release out. This is following the "bug fixes before features"
principle for scheduling releases. Our user base is currently using
2.9.2. I think we'd serve them better by first giving them a 2.9.4
build that fixes bugs with the current code without introducing any
breaking API changes.

Also, if we're developing a new conversion process for 3.X and beyond,
we'll need time to develop that correctly. It's not a trivial task.
Applying bug fixes from 2.9.2 to 2.9.4 shoudl be much easier and could
probably be done manually.

Regarding Mono support... I think we should. I don't know how much
that entails at this point. I know there's an open JIRA ticket for
this at:
https://issues.apache.org/jira/browse/LUCENENET-361

Supporting Mono could be as easy as applying that patch.

I'd also like to address:

https://issues.apache.org/jira/browse/LUCENENET-167

And make a build that can run on the compact framework. I'm not sure
Silverlight support is so important, but Compact Framework support
would be a big win, IMO.

Thanks,
Troy
On Sun, Jan 2, 2011 at 2:03 PM, Michael Herndon <[EMAIL PROTECTED]> wrote:
> The complicated part about having a release for release is that there might
> be certain bugs that are only on our side, thus paying attention to the
> build interval becomes important for people.
>
> i.e.
>
> build 3.0.0.234 = 3.0.0 release
> build 3.0.0.446 = 3.0.0 hotfix
>
> Is there a better way of handling or noting these type of releases?
>
> Is there any benefit of doing all of 3.0.x & 2.9.x releases versus starting
> with the latest of each branch and moving forward from there?
>
> Also are we going to ensure mono support?
>
>
> On Sun, Jan 2, 2011 at 4:36 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:
>
>>
>> Also, was there any pre/post processing involved in these files? Was it
>> manual / scripts etc? Just trying to get a feel for the work involved.
>>
>>
>> > From: [EMAIL PROTECTED]
>> > To: [EMAIL PROTECTED]
>> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
>> > Date: Sun, 2 Jan 2011 19:03:25 +0200
>> >
>> > > The 3.0.X ports should be 100% Sharpen
>> > Why?
>> > What about other alternatives?
>> >
>> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
>> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>> >
>> > DIGY
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
>> > Sent: Saturday, January 01, 2011 1:58 AM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
>> >
>> > We are inheriting the outstanding issues facing the Lucene.Net project.
>> >
>> > This includes remaining committed to providing a line-by-line port
>> > that stays in sync with the Java Lucene releases.
>> >

On 02.01.2011 23:03, Michael Herndon wrote:
> The complicated part about having a release for release is that there might
> be certain bugs that are only on our side, thus paying attention to the
> build interval becomes important for people.
>
> i.e.
>
> build 3.0.0.234 = 3.0.0 release
> build 3.0.0.446 = 3.0.0 hotfix
>
> Is there a better way of handling or noting these type of releases?
>
> Is there any benefit of doing all of 3.0.x&  2.9.x releases versus starting
> with the latest of each branch and moving forward from there?
>
> Also are we going to ensure mono support?

I will take care of the Mono support.

Robert
>
>
> On Sun, Jan 2, 2011 at 4:36 PM, Prescott Nasser<[EMAIL PROTECTED]>wrote:
>
>>
>> Also, was there any pre/post processing involved in these files? Was it
>> manual / scripts etc? Just trying to get a feel for the work involved.
>>
>>
>>> From: [EMAIL PROTECTED]
>>> To: [EMAIL PROTECTED]
>>> Subject: RE: Proposal Stage: Backwards Compatibility / Support
>>> Date: Sun, 2 Jan 2011 19:03:25 +0200
>>>
>>>> The 3.0.X ports should be 100% Sharpen
>>> Why?
>>> What about other alternatives?
>>>
>>> Lucene.java 3.0.3 ==>  .Net Conversion Samples (
>> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>>>
>>> DIGY
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Troy Howard [mailto:[EMAIL PROTECTED]]
>>> Sent: Saturday, January 01, 2011 1:58 AM
>>> To: [EMAIL PROTECTED]
>>> Subject: Re: Proposal Stage: Backwards Compatibility / Support
>>>
>>> We are inheriting the outstanding issues facing the Lucene.Net project.
>>>
>>> This includes remaining committed to providing a line-by-line port
>>> that stays in sync with the Java Lucene releases.
>>>
>>> The project is currently extremely behind schedule on this. The 2.9.2
>>> code base, which is widely used and thus a fairly well received build,
>>> has never been formally packaged as a release (i.e. binary builds,
>>> etc). This is the first order of business to take care of (in terms of
>>> code).
>>>
>>> After that we need to evaluate weather or not to create releases to
>>> match all subsequent releases made by the Java Lucene project.
>>>
>>> Those releases are:
>>> - 3.0.0
>>> - 3.0.1
>>> - 2.9.3
>>> - 3.0.2
>>> - 2.9.4
>>> - 3.0.3
>>>
>>> In the interest of time, we could skip some of the intermediate
>>> releases and just get in sync at 2.9.4 and 3.0.3 releases.
>>>
>>> The 3.0.X ports should be 100% Sharpen conversions and post-processing
>>> scripts. Once written, anyone should be able to repeat the process of
>>> pulling down the appropriate Java Lucene SVN revision, executing the
>>> porting scripts, and building the resulting .NET code, yield a valid
>>> 3.0.X release with a 1:1 matching API.
>>>
>>> This is something we will need to continue being able to do for every
>>> subsequent Java Lucene release.
>>>
>>> This aspect of our development should be completely separate from our
>>> refactoring/re-imagining of a more .NET-like API. They need to be
>>> separate development branches, and possibly even completely different
>>> implementations. We will attempt to reuse as much of the automated
>>> port code as we can, with the understanding that the goal of the
>>> secondary branch is to make a high-quality .NET implementation of
>>> Lucene, rather than a API compatible implementation.
>>>
>>> Thanks,
>>> Troy
>>>
>>>
>>>
>>> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson<[EMAIL PROTECTED]>
>> wrote:
>>>> Maybe we could just bug-fix support the current 2.9.2 codebase unless
>> people
>>>> really need something in 2.9.x
>>>>
>>>> I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
>>>> version.
>>>>
>>>> I'd like to throw another idea into the mix which is perhaps the
>> idiomatic
>>>> version could be created by an automated refactoring of the
>> line-by-line. It
>>>> might be additional upfront work but might make it easier for future
>> changes
>>>> from java lucene to be propagated down.

Here is a Sharpen conversion Alex Thompson did in November:
https://issues.apache.org/jira/secure/attachment/12459581/Lucene.Net.Sharpen20101114.zip
>From my understanding there was no pre/post processing done. I also believe it's 2.9.2, not 3.0.3 as Digy's are.
Here is the JIRA issue for the associated conversations: https://issues.apache.org/jira/browse/LUCENENET-380

> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 13:36:49 -0800
>
>
> Also, was there any pre/post processing involved in these files? Was it manual / scripts etc? Just trying to get a feel for the work involved.
>
>
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> >
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> >
> > Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> >
> > DIGY
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> >
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> >
> > The project is currently extremely behind schedule on this. The 2.9.2
> > code base, which is widely used and thus a fairly well received build,
> > has never been formally packaged as a release (i.e. binary builds,
> > etc). This is the first order of business to take care of (in terms of
> > code).
> >
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> >
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> >
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> >
> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
> > scripts. Once written, anyone should be able to repeat the process of
> > pulling down the appropriate Java Lucene SVN revision, executing the
> > porting scripts, and building the resulting .NET code, yield a valid
> > 3.0.X release with a 1:1 matching API.
> >
> > This is something we will need to continue being able to do for every
> > subsequent Java Lucene release.
> >
> > This aspect of our development should be completely separate from our
> > refactoring/re-imagining of a more .NET-like API. They need to be
> > separate development branches, and possibly even completely different
> > implementations. We will attempt to reuse as much of the automated
> > port code as we can, with the understanding that the goal of the
> > secondary branch is to make a high-quality .NET implementation of
> > Lucene, rather than a API compatible implementation.
> >
> > Thanks,
> > Troy
> >
> >
> >
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless people
> > > really need something in 2.9.x
> > >
> > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > > version.
> > >
> > > I'd like to throw another idea into the mix which is perhaps the idiomatic
> > > version could be created by an automated refactoring of the line-by-line. It
> > > might be additional upfront work but might make it easier for future changes
> > > from java lucene to be propagated down.
> > >
> > > Alex
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
> > > Michael Herndon
     

I would lean towards open source conversion tools since having a robust one
would be useful beyond Lucene. I haven't dug into the sharpen code yet to
see what it would take but I could see creating our own fork of sharpen.

The original conversion I did had a little pre-processing just to get around
some sharpen bugs. It's documented in the issue.

-----Original Message-----
From: Prescott Nasser [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 02, 2011 4:23 PM
To: [EMAIL PROTECTED]
Subject: RE: Proposal Stage: Backwards Compatibility / Support
Here is a Sharpen conversion Alex Thompson did in November:
https://issues.apache.org/jira/secure/attachment/12459581/Lucene.Net.Sharpen
20101114.zip
>From my understanding there was no pre/post processing done. I also believe
it's 2.9.2, not 3.0.3 as Digy's are.
Here is the JIRA issue for the associated conversations:
https://issues.apache.org/jira/browse/LUCENENET-380

> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
> Date: Sun, 2 Jan 2011 13:36:49 -0800
>
>
> Also, was there any pre/post processing involved in these files? Was it
manual / scripts etc? Just trying to get a feel for the work involved.
>
>
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> >
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> >
> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> >
> > DIGY
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> >
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> >
> > The project is currently extremely behind schedule on this. The
> > 2.9.2 code base, which is widely used and thus a fairly well
> > received build, has never been formally packaged as a release (i.e.
> > binary builds, etc). This is the first order of business to take
> > care of (in terms of code).
> >
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> >
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> >
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> >
> > The 3.0.X ports should be 100% Sharpen conversions and
> > post-processing scripts. Once written, anyone should be able to
> > repeat the process of pulling down the appropriate Java Lucene SVN
> > revision, executing the porting scripts, and building the resulting
> > .NET code, yield a valid 3.0.X release with a 1:1 matching API.
> >
> > This is something we will need to continue being able to do for
> > every subsequent Java Lucene release.
> >
> > This aspect of our development should be completely separate from
> > our refactoring/re-imagining of a more .NET-like API. They need to
> > be separate development branches, and possibly even completely
> > different implementations. We will attempt to reuse as much of the
> > automated port code as we can, with the understanding that the goal
> > of the secondary branch is to make a high-quality .NET
> > implementation of Lucene, rather than a API compatible implementation.
> >
> > Thanks,
> > Troy
> >
> >
> >
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]>
wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase
> > > unless people really need something in 2.9.x
down.
inside:

No pre/post processing involved. They are just to see how the output of
these tools looks like.

DIGY

On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Also, was there any pre/post processing involved in these files? Was it
> manual / scripts etc? Just trying to get a feel for the work involved.
>
>
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> >
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> >
> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> >
> > DIGY
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> >
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> >
> > The project is currently extremely behind schedule on this. The 2.9.2
> > code base, which is widely used and thus a fairly well received build,
> > has never been formally packaged as a release (i.e. binary builds,
> > etc). This is the first order of business to take care of (in terms of
> > code).
> >
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> >
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> >
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> >
> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
> > scripts. Once written, anyone should be able to repeat the process of
> > pulling down the appropriate Java Lucene SVN revision, executing the
> > porting scripts, and building the resulting .NET code, yield a valid
> > 3.0.X release with a 1:1 matching API.
> >
> > This is something we will need to continue being able to do for every
> > subsequent Java Lucene release.
> >
> > This aspect of our development should be completely separate from our
> > refactoring/re-imagining of a more .NET-like API. They need to be
> > separate development branches, and possibly even completely different
> > implementations. We will attempt to reuse as much of the automated
> > port code as we can, with the understanding that the goal of the
> > secondary branch is to make a high-quality .NET implementation of
> > Lucene, rather than a API compatible implementation.
> >
> > Thanks,
> > Troy
> >
> >
> >
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]>
> wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless
> people
> > > really need something in 2.9.x
> > >
> > > I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
> > > version.
> > >
> > > I'd like to throw another idea into the mix which is perhaps the
> idiomatic
> > > version could be created by an automated refactoring of the
> line-by-line. It
> > > might be additional upfront work but might make it easier for future
> changes
> > > from java lucene to be propagated down.
> > >
> > > Alex
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
> Of
> > > Michael Herndon
> > > Sent: Friday, December 31, 2010 1:28 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Proposal Stage: Backwards Compatibility / Support
> > >
> > > *Backwards Compatibility / Support: *
> > > This is definitely something we need to cover.
> > >
> > > I'm guessing the obvious choice would be to continue the 2.9.X versions
> > > under sharpen, maintain the current api thats has java idioms so that

A couple of different packages have been mentioned for the conversion.  What criteria should be used to determine the best software to use?

Given the items mention by troy.  How do we metric these items for a comparison?

1. Automated, Repeatable, and Well Documented (e.g. a script or build task with minimal human involvement)
2. Based on free, open source tools
3. Performs a reasonable and high quality conversion that presents a
1:1 API between Java/C# and the same functionality and performance

Note:  Number 2 might be changed to just the software being free to the Lucene.Net project.

How much up front work do we do to decide on the correct conversion tool?  Does the team think we need to get a working source from each tool and then decide?  Should we convert a single file?  Should we convert an analyzer?

Scott
-----Original Message-----
From: digy digy [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 03, 2011 2:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Proposal Stage: Backwards Compatibility / Support

No pre/post processing involved. They are just to see how the output of
these tools looks like.

DIGY

On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> Also, was there any pre/post processing involved in these files? Was it
> manual / scripts etc? Just trying to get a feel for the work involved.
>
>
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > Date: Sun, 2 Jan 2011 19:03:25 +0200
> >
> > > The 3.0.X ports should be 100% Sharpen
> > Why?
> > What about other alternatives?
> >
> > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> >
> > DIGY
> >
> >
> >
> > -----Original Message-----
> > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > Sent: Saturday, January 01, 2011 1:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > We are inheriting the outstanding issues facing the Lucene.Net project.
> >
> > This includes remaining committed to providing a line-by-line port
> > that stays in sync with the Java Lucene releases.
> >
> > The project is currently extremely behind schedule on this. The 2.9.2
> > code base, which is widely used and thus a fairly well received build,
> > has never been formally packaged as a release (i.e. binary builds,
> > etc). This is the first order of business to take care of (in terms of
> > code).
> >
> > After that we need to evaluate weather or not to create releases to
> > match all subsequent releases made by the Java Lucene project.
> >
> > Those releases are:
> > - 3.0.0
> > - 3.0.1
> > - 2.9.3
> > - 3.0.2
> > - 2.9.4
> > - 3.0.3
> >
> > In the interest of time, we could skip some of the intermediate
> > releases and just get in sync at 2.9.4 and 3.0.3 releases.
> >
> > The 3.0.X ports should be 100% Sharpen conversions and post-processing
> > scripts. Once written, anyone should be able to repeat the process of
> > pulling down the appropriate Java Lucene SVN revision, executing the
> > porting scripts, and building the resulting .NET code, yield a valid
> > 3.0.X release with a 1:1 matching API.
> >
> > This is something we will need to continue being able to do for every
> > subsequent Java Lucene release.
> >
> > This aspect of our development should be completely separate from our
> > refactoring/re-imagining of a more .NET-like API. They need to be
> > separate development branches, and possibly even completely different
> > implementations. We will attempt to reuse as much of the automated
> > port code as we can, with the understanding that the goal of the
> > secondary branch is to make a high-quality .NET implementation of
> > Lucene, rather than a API compatible implementation.
> >
> > Thanks,
> > Troy
> >
> >
> >
> > On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]>
> wrote:
> > > Maybe we could just bug-fix support the current 2.9.2 codebase unless
This message (and any associated files) is intended only for the
use of the individual or entity to which it is addressed and may
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient
you are hereby notified that any dissemination, copying or
distribution of this message, or files associated with this message,
is strictly prohibited. If you have received this message in error,
please notify us immediately by replying to the message and deleting
it from your computer.  Thank you, King Industries, Inc.

For number 2, you're spot on - free to the Lucene.Net project is probably the relevant piece. Someone mentioned having an open source tool that we could customize directly for our conversion purposes would be useful - but I think that really goes to 1 and 3 - if we can create pre/post processing scripts that uses a non open tool what does it matter.
I hope people are working with the code digy linked to a few days ago to really evaluate the extend of the extra work required to get those to build (I know I have spent some time digging in and I would like to spend a bit more time). I also hope someone is taking a lead on the Sharpen convert - I don't have any of the stuff on my system, and don't really have any knowledge of it, so I am hesitant to jump in and try to make a 3.0.3 port - is anyone working on that?
I don't think we need them to be buildable , but we need enough people familiar with the different options so that we can have an informed decision.

I would ask that everyone download digy's conversions and begin to play with those. I would also ask that someone who has sharpen or is familiar with it to please step up and do a quick conversion of lucene 3.0.3 and give the group a link to that. This would give us 3 conversion tools to evalute.
If anyone can step up and do a 3.0.3 Sharpen conversion in the next couple of days please let us know, otherwise I will get started downloading /installing the required stuff and digging into Sharpen documentation, I think we need to get this ball rolling.
Also, I'm not sure how quickly we need to make a decision, since Troy hasn't submitted a proposal to the ASF. I have no idea how long that process might take.
~Prescott
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Date: Tue, 4 Jan 2011 16:37:12 -0500
> Subject: RE: Proposal Stage: Backwards Compatibility / Support
>
> A couple of different packages have been mentioned for the conversion.  What criteria should be used to determine the best software to use?
>
> Given the items mention by troy.  How do we metric these items for a comparison?
>
> 1. Automated, Repeatable, and Well Documented (e.g. a script or build task with minimal human involvement)
> 2. Based on free, open source tools
> 3. Performs a reasonable and high quality conversion that presents a
> 1:1 API between Java/C# and the same functionality and performance
>
> Note:  Number 2 might be changed to just the software being free to the Lucene.Net project.
>
> How much up front work do we do to decide on the correct conversion tool?  Does the team think we need to get a working source from each tool and then decide?  Should we convert a single file?  Should we convert an analyzer?
>
>
>
> Scott
>
>
> -----Original Message-----
> From: digy digy [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 03, 2011 2:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
>
> No pre/post processing involved. They are just to see how the output of
> these tools looks like.
>
> DIGY
>
> On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser <[EMAIL PROTECTED]>wrote:
>
> >
> > Also, was there any pre/post processing involved in these files? Was it
> > manual / scripts etc? Just trying to get a feel for the work involved.
> >
> >
> > > From: [EMAIL PROTECTED]
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > > Date: Sun, 2 Jan 2011 19:03:25 +0200
> > >
> > > > The 3.0.X ports should be 100% Sharpen
> > > Why?
> > > What about other alternatives?
> > >
> > > Lucene.java 3.0.3 ==> .Net Conversion Samples (
> > http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
> > >
> > > DIGY
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Troy Howard [mailto:[EMAIL PROTECTED]]
> > > Sent: Saturday, January 01, 2011 1:58 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Proposal Stage: Backwards Compatibility / Support
     

I could probably take a stab at Sharpen this weekend. I need to pull down
the java version of lucene anyways.

On Wed, Jan 5, 2011 at 1:50 AM, Prescott Nasser <[EMAIL PROTECTED]>wrote:

>
> For number 2, you're spot on - free to the Lucene.Net project is probably
> the relevant piece. Someone mentioned having an open source tool that we
> could customize directly for our conversion purposes would be useful - but I
> think that really goes to 1 and 3 - if we can create pre/post processing
> scripts that uses a non open tool what does it matter.
> I hope people are working with the code digy linked to a few days ago to
> really evaluate the extend of the extra work required to get those to build
> (I know I have spent some time digging in and I would like to spend a bit
> more time). I also hope someone is taking a lead on the Sharpen convert - I
> don't have any of the stuff on my system, and don't really have any
> knowledge of it, so I am hesitant to jump in and try to make a 3.0.3 port -
> is anyone working on that?
> I don't think we need them to be buildable , but we need enough people
> familiar with the different options so that we can have an informed
> decision.
>
> I would ask that everyone download digy's conversions and begin to play
> with those. I would also ask that someone who has sharpen or is familiar
> with it to please step up and do a quick conversion of lucene 3.0.3 and give
> the group a link to that. This would give us 3 conversion tools to evalute.
> If anyone can step up and do a 3.0.3 Sharpen conversion in the next couple
> of days please let us know, otherwise I will get started downloading
> /installing the required stuff and digging into Sharpen documentation, I
> think we need to get this ball rolling.
> Also, I'm not sure how quickly we need to make a decision, since Troy
> hasn't submitted a proposal to the ASF. I have no idea how long that process
> might take.
> ~Prescott
> > From: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Date: Tue, 4 Jan 2011 16:37:12 -0500
> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> >
> > A couple of different packages have been mentioned for the conversion.
>  What criteria should be used to determine the best software to use?
> >
> > Given the items mention by troy.  How do we metric these items for a
> comparison?
> >
> > 1. Automated, Repeatable, and Well Documented (e.g. a script or build
> task with minimal human involvement)
> > 2. Based on free, open source tools
> > 3. Performs a reasonable and high quality conversion that presents a
> > 1:1 API between Java/C# and the same functionality and performance
> >
> > Note:  Number 2 might be changed to just the software being free to the
> Lucene.Net project.
> >
> > How much up front work do we do to decide on the correct conversion tool?
>  Does the team think we need to get a working source from each tool and then
> decide?  Should we convert a single file?  Should we convert an analyzer?
> >
> >
> >
> > Scott
> >
> >
> > -----Original Message-----
> > From: digy digy [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, January 03, 2011 2:26 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Proposal Stage: Backwards Compatibility / Support
> >
> > No pre/post processing involved. They are just to see how the output of
> > these tools looks like.
> >
> > DIGY
> >
> > On Sun, Jan 2, 2011 at 11:36 PM, Prescott Nasser <[EMAIL PROTECTED]
> >wrote:
> >
> > >
> > > Also, was there any pre/post processing involved in these files? Was it
> > > manual / scripts etc? Just trying to get a feel for the work involved.
> > >
> > >
> > > > From: [EMAIL PROTECTED]
> > > > To: [EMAIL PROTECTED]
> > > > Subject: RE: Proposal Stage: Backwards Compatibility / Support
> > > > Date: Sun, 2 Jan 2011 19:03:25 +0200
> > > >
> > > > > The 3.0.X ports should be 100% Sharpen
> > > > Why?
> > > > What about other alternatives?
> > > >
> > > > Lucene.java 3.0.3 ==> .Net Conversion Samples (

Michael Herndon
Senior Developer ([EMAIL PROTECTED])
804.767.0083

[connect online]
http://www.opensourceconnections.com
http://www.amptools.net
http://www.linkedin.com/pub/michael-herndon/4/893/23
http://www.facebook.com/amptools.net
http://www.twitter.com/amptools-net

Scripted, automated and repeatable are mantras to live by. Why not
take it all the way?

What I mean by this is setting up the new, fresh, Lucene 3.0 project
to do something like the following:

1) setup a CI server that grabs the current stable java source
automatically from SVN and runs our conversion tool [whatever it ends
up being] on said bits.
2) CI server then commits this to source control somewhere -- I'd
actually vote a branch per conversion here for a variety of reasons.
3) the actual lucene project references the automatically created bits
which can be merged in when we want to support a new drop from the
Java trunk.

This covers a few bases that would likely be pain points:

a) Keeps the conversion bits out of the .NET trunk. Meaning that most
users won't need [insert java toolz] to build/run the project. We are
just shipping C# here.
b) Makes it easy to fix on an exact java SVN revision we are based off
of. And makes it easy to change that revision should we need to
presuming we get the updated project organized right.
b) Will hopefully help us keep in lock step with the java bits going
forward -- we will at least be catching every update.

Thoughts?

On Wed, Jan 5, 2011 at 9:16 AM, Michael Herndon <[EMAIL PROTECTED]> wrote:
> I could probably take a stab at Sharpen this weekend. I need to pull down
> the java version of lucene anyways.
>
> On Wed, Jan 5, 2011 at 1:50 AM, Prescott Nasser
> <[EMAIL PROTECTED]>wrote:
>
>>
>> For number 2, you're spot on - free to the Lucene.Net project is probably
>> the relevant piece. Someone mentioned having an open source tool that we
>> could customize directly for our conversion purposes would be useful - but
>> I
>> think that really goes to 1 and 3 - if we can create pre/post processing
>> scripts that uses a non open tool what does it matter.
>> I hope people are working with the code digy linked to a few days ago to
>> really evaluate the extend of the extra work required to get those to
>> build
>> (I know I have spent some time digging in and I would like to spend a bit
>> more time). I also hope someone is taking a lead on the Sharpen convert -
>> I
>> don't have any of the stuff on my system, and don't really have any
>> knowledge of it, so I am hesitant to jump in and try to make a 3.0.3 port
>> -
>> is anyone working on that?
>> I don't think we need them to be buildable , but we need enough people
>> familiar with the different options so that we can have an informed
>> decision.
>>
>> I would ask that everyone download digy's conversions and begin to play
>> with those. I would also ask that someone who has sharpen or is familiar
>> with it to please step up and do a quick conversion of lucene 3.0.3 and
>> give
>> the group a link to that. This would give us 3 conversion tools to
>> evalute.
>> If anyone can step up and do a 3.0.3 Sharpen conversion in the next couple
>> of days please let us know, otherwise I will get started downloading
>> /installing the required stuff and digging into Sharpen documentation, I
>> think we need to get this ball rolling.
>> Also, I'm not sure how quickly we need to make a decision, since Troy
>> hasn't submitted a proposal to the ASF. I have no idea how long that
>> process
>> might take.
>> ~Prescott
>> > From: [EMAIL PROTECTED]
>> > To: [EMAIL PROTECTED]
>> > Date: Tue, 4 Jan 2011 16:37:12 -0500
>> > Subject: RE: Proposal Stage: Backwards Compatibility / Support
>> >
>> > A couple of different packages have been mentioned for the conversion.
>>  What criteria should be used to determine the best software to use?
>> >
>> > Given the items mention by troy.  How do we metric these items for a
>> comparison?
>> >
>> > 1. Automated, Repeatable, and Well Documented (e.g. a script or build
>> task with minimal human involvement)
>> > 2. Based on free, open source tools
>> > 3. Performs a reasonable and high quality conversion that presents a
>> > 1:1 API between Java/C# and the same functionality and performance

One thing to note... Neither of those conversions create buildable code.

The j2cstranslator version, for example, included Java language
constructions like "import", "throws", etc.. which of course don't
compile.

The Tangible one has over 300 errors of various types. It's unclear
how much manual work would be required to fix this, or if that work
could be sufficiently generalized to be scriptable.

Thanks,
Troy

On Sun, Jan 2, 2011 at 9:03 AM, Digy <[EMAIL PROTECTED]> wrote:
>> The 3.0.X ports should be 100% Sharpen
> Why?
> What about other alternatives?
>
> Lucene.java 3.0.3 ==> .Net Conversion Samples ( http://people.apache.org/~digy/Lucene.Net.3.0.3.zip )
>
> DIGY
>
>
>
> -----Original Message-----
> From: Troy Howard [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 01, 2011 1:58 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Proposal Stage: Backwards Compatibility / Support
>
> We are inheriting the outstanding issues facing the Lucene.Net project.
>
> This includes remaining committed to providing a line-by-line port
> that stays in sync with the Java Lucene releases.
>
> The project is currently extremely behind schedule on this. The 2.9.2
> code base, which is widely used and thus a fairly well received build,
> has never been formally packaged as a release (i.e. binary builds,
> etc). This is the first order of business to take care of (in terms of
> code).
>
> After that we need to evaluate weather or not to create releases to
> match all subsequent releases made by the Java Lucene project.
>
> Those releases are:
> - 3.0.0
> - 3.0.1
> - 2.9.3
> - 3.0.2
> - 2.9.4
> - 3.0.3
>
> In the interest of time, we could skip some of the intermediate
> releases and just get in sync at 2.9.4 and 3.0.3 releases.
>
> The 3.0.X ports should be 100% Sharpen conversions and post-processing
> scripts. Once written, anyone should be able to repeat the process of
> pulling down the appropriate Java Lucene SVN revision, executing the
> porting scripts, and building the resulting .NET code, yield a valid
> 3.0.X release with a 1:1 matching API.
>
> This is something we will need to continue being able to do for every
> subsequent Java Lucene release.
>
> This aspect of our development should be completely separate from our
> refactoring/re-imagining of a more .NET-like API. They need to be
> separate development branches, and possibly even completely different
> implementations. We will attempt to reuse as much of the automated
> port code as we can, with the understanding that the goal of the
> secondary branch is to make a high-quality .NET implementation of
> Lucene, rather than a API compatible implementation.
>
> Thanks,
> Troy
>
>
>
> On Fri, Dec 31, 2010 at 3:29 PM, Alex Thompson <[EMAIL PROTECTED]> wrote:
>> Maybe we could just bug-fix support the current 2.9.2 codebase unless people
>> really need something in 2.9.x
>>
>> I think there would be a 3.0.x line-by-line port and a 3.0.x idiomatic
>> version.
>>
>> I'd like to throw another idea into the mix which is perhaps the idiomatic
>> version could be created by an automated refactoring of the line-by-line. It
>> might be additional upfront work but might make it easier for future changes
>> from java lucene to be propagated down.
>>
>> Alex
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
>> Michael Herndon
>> Sent: Friday, December 31, 2010 1:28 PM
>> To: [EMAIL PROTECTED]
>> Subject: Proposal Stage: Backwards Compatibility / Support
>>
>> *Backwards Compatibility / Support: *
>> This is definitely something we need to cover.
>>
>> I'm guessing the obvious choice would be to continue the 2.9.X versions
>> under sharpen, maintain the current api thats has java idioms so that people
>> can continue to use it, release patches, ensure stability with the current
>> community. This would be important for people who have built products on top
>> of lucene.net.
>>
>> The 3.0 version should probably match java in terms of breaking the api due