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: thowar...@gmail.com > Date: Sun, 2 Jan 2011 15:15:39 -0800 > Subject: Re: Proposal Stage: Backwards Compatibility / Support > To: lucene-net-dev@lucene.apache.org > > 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 <geobmx...@hotmail.com> 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: digyd...@gmail.com > >> To: lucene-net-dev@lucene.apache.org > >> 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:thowar...@gmail.com] > >> Sent: Saturday, January 01, 2011 1:58 AM > >> To: lucene-net-dev@lucene.apache.org > >> 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 <pierogi...@hotmail.com> > >> 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: mhern...@amptools.net [mailto:mhern...@amptools.net] On Behalf Of > >> > Michael Herndon > >> > Sent: Friday, December 31, 2010 1:28 PM > >> > To: lucene-net-dev@lucene.apache.org > >> > 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 > >> > > >> > > >> > >
