Details

      Description

      This task is to evaluate Sharpen as a port tool for Lucene.Net.

      The files to be evaluated are attached. We need to run those files (which are off Java Lucene 2.9.2) against Sharpen and compare the result against JLCA result.

      1. TestDateFilter.java
        6 kB
        George Aroush
      2. TestBufferedIndexInput.java
        12 kB
        George Aroush
      3. QueryParser.java
        58 kB
        George Aroush
      4. NIOFSDirectory.java
        6 kB
        George Aroush
      5. Lucene.Net.Sharpen20101114.zip
        1.40 MB
        Alex Thompson
      6. Lucene.Net.Sharpen20101104.zip
        614 kB
        Alex Thompson
      7. Lucene.Net.3_0_3_Sharpen20110106.zip
        1.81 MB
        Alex Thompson
      8. IndexWriter.java
        198 kB
        George Aroush
      9. 3.0.2_JavaToCSharpConverter_NoPostProcessing.zip
        54 kB
        Prescott Nasser
      10. 3.0.2_JavaToCSharpConverter_AfterPostProcessing.zip
        55 kB
        Prescott Nasser

        Activity

        Hide
        Aaron Powell added a comment - - edited

        I've created an external repository to make it easier for managing the testing of the different tools available for converting Java to .NET, available here: https://hg.slace.biz/lucene-porting

        Note this is only for finding a suitable tool for the conversion and will be rolled back to ASF once a tool is found.

        Show
        Aaron Powell added a comment - - edited I've created an external repository to make it easier for managing the testing of the different tools available for converting Java to .NET, available here: https://hg.slace.biz/lucene-porting Note this is only for finding a suitable tool for the conversion and will be rolled back to ASF once a tool is found.
        Hide
        Prescott Nasser added a comment -

        Great work Aaron.

        Would it be possible for those who are committing / submitting different conversions provide some details:

        1. Pre / Post processing work required to get it to the "current state" that is in the repository
        2. A comment or two about the current state - does it build, what .net version depedancies it might have, known issues with the conversion

        Both details could be broad strokes, not specifics. I'm just kind of jumping in here, this information would certainly help me.

        Show
        Prescott Nasser added a comment - Great work Aaron. Would it be possible for those who are committing / submitting different conversions provide some details: 1. Pre / Post processing work required to get it to the "current state" that is in the repository 2. A comment or two about the current state - does it build, what .net version depedancies it might have, known issues with the conversion Both details could be broad strokes, not specifics. I'm just kind of jumping in here, this information would certainly help me.
        Hide
        Aaron Powell added a comment -

        Good idea, would that be best put on here or on the wiki at bitbucket?

        Show
        Aaron Powell added a comment - Good idea, would that be best put on here or on the wiki at bitbucket?
        Hide
        Prescott Nasser added a comment -

        I'm not sure we have a wiki yet, but I like the idea of having it there, that would give a nice place to hold a changing discussion and update information regarding each tool. Not to mention we can start to build out the wiki a bit more.

        I'd say put it wherever is convient for you at the moment and let everyone follow suit for now, when the wiki is ready to rock we can port over the conversation / notes.

        Show
        Prescott Nasser added a comment - I'm not sure we have a wiki yet, but I like the idea of having it there, that would give a nice place to hold a changing discussion and update information regarding each tool. Not to mention we can start to build out the wiki a bit more. I'd say put it wherever is convient for you at the moment and let everyone follow suit for now, when the wiki is ready to rock we can port over the conversation / notes.
        Hide
        Aaron Powell added a comment -

        I've started off the wiki over at bitbucket - http://hg.slace.biz/lucene-porting/wiki/Home
        It's also just a mercurial repo so anyone can update it and send back pull requests: http://hg.slace.biz/lucene-porting/wiki

        Show
        Aaron Powell added a comment - I've started off the wiki over at bitbucket - http://hg.slace.biz/lucene-porting/wiki/Home It's also just a mercurial repo so anyone can update it and send back pull requests: http://hg.slace.biz/lucene-porting/wiki
        Hide
        Igor Latyshev added a comment -

        I'd like to sign up for this task. What do I need to do?

        Show
        Igor Latyshev added a comment - I'd like to sign up for this task. What do I need to do?
        Hide
        George Aroush added a comment -

        Few points:

        1) Work on ASF projects need to be done at ASF. Please use this JIRA issue and the mailing list to communicate questions, report progress and results.
        2) The converted files need to be attached to this JIRA issue, so we have a record of it and able to evaluate by all.
        3) Prescott point of highlighting pre / post processing work is a good one and important. Please write this up as you work on this task.
        4) More than one person can work on this JIRA issue, just keep everyone posted.

        My expected outcome of this JIRA issue is:

        1) What pre / post processing did you use if any? It would also help to show the raw output with and without the pre processing.
        2) How close is the result of those 5 attached files to the existing converted C# files? This includes the layout of the code (was anything lost or considerably change?) but most importantly, are the public APIs consistent?

        The reason why I picked those 5 files is because those are the ones JLCA has some of the most issues with, so it should be a good barometer seeing how Sharpen does.

        Show
        George Aroush added a comment - Few points: 1) Work on ASF projects need to be done at ASF. Please use this JIRA issue and the mailing list to communicate questions, report progress and results. 2) The converted files need to be attached to this JIRA issue, so we have a record of it and able to evaluate by all. 3) Prescott point of highlighting pre / post processing work is a good one and important. Please write this up as you work on this task. 4) More than one person can work on this JIRA issue, just keep everyone posted. My expected outcome of this JIRA issue is: 1) What pre / post processing did you use if any? It would also help to show the raw output with and without the pre processing. 2) How close is the result of those 5 attached files to the existing converted C# files? This includes the layout of the code (was anything lost or considerably change?) but most importantly, are the public APIs consistent? The reason why I picked those 5 files is because those are the ones JLCA has some of the most issues with, so it should be a good barometer seeing how Sharpen does.
        Hide
        Alex Thompson added a comment -

        Attached Lucene.Net.Sharpen20101104.zip which has the jars for Sharpen and a baseline Ant script just to get started.

        Sharpen is an Eclipse plugin. (so you can just drop the jars into the eclipse/plugins directory)
        Some limited documentation is here: http://developer.db4o.com/documentation/reference/db4o-7.12/java/reference/html/reference/sharpen.html

        Show
        Alex Thompson added a comment - Attached Lucene.Net.Sharpen20101104.zip which has the jars for Sharpen and a baseline Ant script just to get started. Sharpen is an Eclipse plugin. (so you can just drop the jars into the eclipse/plugins directory) Some limited documentation is here: http://developer.db4o.com/documentation/reference/db4o-7.12/java/reference/html/reference/sharpen.html
        Hide
        Aaron Powell added a comment -

        George,

        The reason I spun up the external repo is so that it's easy to track changes and have a collaborative effort trying to find the right tool for the job.

        Can we spin up a repo under the ASF so we can collaboratively work on a solution?

        Show
        Aaron Powell added a comment - George, The reason I spun up the external repo is so that it's easy to track changes and have a collaborative effort trying to find the right tool for the job. Can we spin up a repo under the ASF so we can collaboratively work on a solution?
        Hide
        Mauricio Scheffer added a comment -

        @Aaron Powell: the ASF has official Git mirrors at github, see https://github.com/apache/lucene.net
        It's outdated so there seems to be a problem with the ASF sync, I'd notify the ASF infrastructure team about it.
        See also http://www.apache.org/dev/git.html

        Show
        Mauricio Scheffer added a comment - @Aaron Powell: the ASF has official Git mirrors at github, see https://github.com/apache/lucene.net It's outdated so there seems to be a problem with the ASF sync, I'd notify the ASF infrastructure team about it. See also http://www.apache.org/dev/git.html
        Hide
        Prescott Nasser added a comment -

        I pulled out the relevent converted files from Aaron's Port. It was missing the two Test files, so there are only 3 files. Two versions with post processing and without it. Hopefully that helps people compare. I took a look at the sharpen repository that was put up - seems to be missing a lot of files - or I'm just tired.

        Show
        Prescott Nasser added a comment - I pulled out the relevent converted files from Aaron's Port. It was missing the two Test files, so there are only 3 files. Two versions with post processing and without it. Hopefully that helps people compare. I took a look at the sharpen repository that was put up - seems to be missing a lot of files - or I'm just tired.
        Hide
        Alex Thompson added a comment -

        The sharpen files I put up are not a full port. Sharpen stops when it finds something you didn't give it a mapping for. What's there is an initial config that converts a few files and needs to be extended.

        Show
        Alex Thompson added a comment - The sharpen files I put up are not a full port. Sharpen stops when it finds something you didn't give it a mapping for. What's there is an initial config that converts a few files and needs to be extended.
        Hide
        Prescott Nasser added a comment -

        Alex, are you familiar enough with Sharpen and the ability to do those mappings to produce the 5 files posted so that we can do some comparisons to determine if Sharpen or JavaToCSharp is a better way to go?

        Also, JavaToCSharp isn't free - so that might be a hinderance because we would always require someone with that software to continue with releases.

        Show
        Prescott Nasser added a comment - Alex, are you familiar enough with Sharpen and the ability to do those mappings to produce the 5 files posted so that we can do some comparisons to determine if Sharpen or JavaToCSharp is a better way to go? Also, JavaToCSharp isn't free - so that might be a hinderance because we would always require someone with that software to continue with releases.
        Hide
        Alex Thompson added a comment -

        yes i'll try to make progress this weekend.

        Show
        Alex Thompson added a comment - yes i'll try to make progress this weekend.
        Hide
        Alex Thompson added a comment -

        Lucene.Net.Sharpen20101114.zip is a full run of 2.9.2 with all the output .cs including the 5 files above.
        Sharpen seems to have a problem with "assert" so I ended up commenting out all asserts just to get going. I also commented out a few other isolated lines that were stopping the conversion. I included a patch file that shows all of this preprocessing.

        Show
        Alex Thompson added a comment - Lucene.Net.Sharpen20101114.zip is a full run of 2.9.2 with all the output .cs including the 5 files above. Sharpen seems to have a problem with "assert" so I ended up commenting out all asserts just to get going. I also commented out a few other isolated lines that were stopping the conversion. I included a patch file that shows all of this preprocessing.
        Hide
        Alex Thompson added a comment -

        George,
        Can you post your setup, pre/post processing and output from JLCA so we can compare?

        Show
        Alex Thompson added a comment - George, Can you post your setup, pre/post processing and output from JLCA so we can compare?
        Hide
        Prescott Nasser added a comment -

        Alex,

        did you do any post processing to clean up the files? or just the pre processing?

        Show
        Prescott Nasser added a comment - Alex, did you do any post processing to clean up the files? or just the pre processing?
        Hide
        Prescott Nasser added a comment -

        Aaron any chance you can run 2.9.2 through JavaToCSharp converter? so we have those files to compare, rather than the 3.0.2 ones?

        Show
        Prescott Nasser added a comment - Aaron any chance you can run 2.9.2 through JavaToCSharp converter? so we have those files to compare, rather than the 3.0.2 ones?
        Hide
        Alex Thompson added a comment -

        its the raw output, no post processing.

        Show
        Alex Thompson added a comment - its the raw output, no post processing.
        Hide
        Prescott Nasser added a comment -

        IndexWriter.java to IndexWriter.cs (Sharpen) - thoughts and observations

        Some generic comments:
        1. Some comments that are nexted withint methods and functions get moved around. Some are merged with the summaries of the next function, not a big deal
        2. With asserts commented out BEFORE the conversion, sometimes they get moved to incorrect places (part of 1).
        Check out lines 3224(java) and 4242(.cs). This shoudln't be to hard to diagnose, once we determine how we are going to
        convert assert to .net, we can do a quick search for assert to find these kinds of things
        3. Sharpen libraries show up a few places - my intuition says that we need to get rid of those? Am I correct on that?
        3. formatting needs some work imo
        4. The CS - SetDiagnostics(...) just feels wrong - diagnostics["java.vendor"] = ..

        I think the biggest question in my head is how do we deal with the asserts - the rest seems ok to me.

        Specifics:

        IndexWriter.java
        line 506: final int numSegments = infos.size();
        IndexWriter.cs
        line 622: int numSegments = infos.Count;

        Is this missing a final? (does it matter?) This happens in a number of places.

        IndexWriter.java
        line 786: notifyAll();
        IndexWriter.cs
        line 1018: Sharpen.Runtime.NotifyAll(this);

        Why is Sharpen referenced here? Is this just part of the assertion stuff? I don't think
        we want to have this line in the final build.

        IndexWriter.java
        line 789: synchronized final boolean isOpen(boolean includePendingClose) {
        IndexWriter.cs
        line 1022: internal bool IsOpen(bool includePendingClose)

        The method declaration is fine - the question I have is in the implimentation, for c# it
        uses the lock (this) to replace the synchronized java keyword - but then it's statment is:
        return !(closed || (includePendingClose && closing));

        In other cases, it would be this.closed, and this.closing (or this._enclosing.closed)..
        this shows up a number of other places. It's likely my misunderstanding of how locking works
        in c#, but wouldn't we want the this. infront of those?

        This happens in a few places

        IndexWriter.java
        line 1575: synced.addAll(segmentInfos.files(directory, true));
        IndexWriter.cs
        line 2102: Sharpen.Collections.AddAll(synced, segmentInfos.Files(directory, true));

        Again we reference Sharpen here - I'm not sure why, but my intuition says this is not what we want.
        (search on Sharpen. turns this up a number of places)

        Show
        Prescott Nasser added a comment - IndexWriter.java to IndexWriter.cs (Sharpen) - thoughts and observations Some generic comments: 1. Some comments that are nexted withint methods and functions get moved around. Some are merged with the summaries of the next function, not a big deal 2. With asserts commented out BEFORE the conversion, sometimes they get moved to incorrect places (part of 1). Check out lines 3224(java) and 4242(.cs). This shoudln't be to hard to diagnose, once we determine how we are going to convert assert to .net, we can do a quick search for assert to find these kinds of things 3. Sharpen libraries show up a few places - my intuition says that we need to get rid of those? Am I correct on that? 3. formatting needs some work imo 4. The CS - SetDiagnostics(...) just feels wrong - diagnostics ["java.vendor"] = .. I think the biggest question in my head is how do we deal with the asserts - the rest seems ok to me. Specifics: IndexWriter.java line 506: final int numSegments = infos.size(); IndexWriter.cs line 622: int numSegments = infos.Count; Is this missing a final? (does it matter?) This happens in a number of places. IndexWriter.java line 786: notifyAll(); IndexWriter.cs line 1018: Sharpen.Runtime.NotifyAll(this); Why is Sharpen referenced here? Is this just part of the assertion stuff? I don't think we want to have this line in the final build. IndexWriter.java line 789: synchronized final boolean isOpen(boolean includePendingClose) { IndexWriter.cs line 1022: internal bool IsOpen(bool includePendingClose) The method declaration is fine - the question I have is in the implimentation, for c# it uses the lock (this) to replace the synchronized java keyword - but then it's statment is: return !(closed || (includePendingClose && closing)); In other cases, it would be this.closed, and this.closing (or this._enclosing.closed).. this shows up a number of other places. It's likely my misunderstanding of how locking works in c#, but wouldn't we want the this. infront of those? This happens in a few places IndexWriter.java line 1575: synced.addAll(segmentInfos.files(directory, true)); IndexWriter.cs line 2102: Sharpen.Collections.AddAll(synced, segmentInfos.Files(directory, true)); Again we reference Sharpen here - I'm not sure why, but my intuition says this is not what we want. (search on Sharpen. turns this up a number of places)
        Hide
        Prescott Nasser added a comment -

        Anyone else had a chance to take a look at the conversions? Anyone care?

        Show
        Prescott Nasser added a comment - Anyone else had a chance to take a look at the conversions? Anyone care?
        Hide
        Neal Granroth added a comment -

        I had looked them over several weeks ago, but had no additional comment than the one you'd made about needing to find a way to eliminate conversions which make use of Sharpen-specific classes. Hopefully others with a larger stake than I in keeping the project alive will chime in.

        Show
        Neal Granroth added a comment - I had looked them over several weeks ago, but had no additional comment than the one you'd made about needing to find a way to eliminate conversions which make use of Sharpen-specific classes. Hopefully others with a larger stake than I in keeping the project alive will chime in.
        Hide
        Alex Thompson added a comment -

        Uploaded Lucene.Net.3_0_3_Sharpen20110106.zip which is a full run of 3.0.3.

        I modified sharpen and implemented "assert". There's still some problems with enums and anonymous classes that I had to comment out. The zip includes all the output CS, jars for my build of sharpen, patch file of preprocessing, patch file of sharpen and Ant config scripts.
        Enjoy.

        Show
        Alex Thompson added a comment - Uploaded Lucene.Net.3_0_3_Sharpen20110106.zip which is a full run of 3.0.3. I modified sharpen and implemented "assert". There's still some problems with enums and anonymous classes that I had to comment out. The zip includes all the output CS, jars for my build of sharpen, patch file of preprocessing, patch file of sharpen and Ant config scripts. Enjoy.
        Hide
        Neal Granroth added a comment -

        Thanks Alex,

        What would be the plan for handling the Sharpen artifacts that prevent the converted code from being built by the .NET SDK compiler?

        Do you envision a post-conversion script to strip out statements like:
        using Java.Lang
        using Java.IO

        and replace Sharpen-specific classes with standard .NET classes:
        Sharpen.Collections.*
        Sharpen.Runtime.*

        Show
        Neal Granroth added a comment - Thanks Alex, What would be the plan for handling the Sharpen artifacts that prevent the converted code from being built by the .NET SDK compiler? Do you envision a post-conversion script to strip out statements like: using Java.Lang using Java.IO and replace Sharpen-specific classes with standard .NET classes: Sharpen.Collections.* Sharpen.Runtime.*
        Hide
        Alex Thompson added a comment -

        Ideally I think the goal would be to modify sharpen till it outputs buildable C# with no pre/post.

        Sharpen is build on the abstract syntax tree components of Eclipse so it seems pretty workable.

        Show
        Alex Thompson added a comment - Ideally I think the goal would be to modify sharpen till it outputs buildable C# with no pre/post. Sharpen is build on the abstract syntax tree components of Eclipse so it seems pretty workable.
        Hide
        Troy Howard added a comment -

        Scheduled task. We should come to a decision about our preferred tooling for this and start work on actual implementation by March 1st.

        Show
        Troy Howard added a comment - Scheduled task. We should come to a decision about our preferred tooling for this and start work on actual implementation by March 1st.
        Hide
        Prescott Nasser added a comment -

        I see this is assigned to me - but I'm hoping some other folks have been playing with sharpen? Also, at this point what are our other options? We could do something like tangible softwares java to C# - but that costs money and is likely not as extensible

        Show
        Prescott Nasser added a comment - I see this is assigned to me - but I'm hoping some other folks have been playing with sharpen? Also, at this point what are our other options? We could do something like tangible softwares java to C# - but that costs money and is likely not as extensible
        Hide
        Troy Howard added a comment -

        So far Sharpen seems to be the most viable option.

        Worth noting: NGit (a .NET port of JGit) is also using Sharpen to do their code generation. They have pretty good documentation about the process. They have developed a bunch of support classes to enable the Sharpen conversion. I was thinking of contacting Lluis (developer of NGit), and seeing if he would be able to help us get our Sharpen setup rolling, or at least help evaluate our use case.

        Anyhow, check out the project at:

        https://github.com/slluis/ngit

        Show
        Troy Howard added a comment - So far Sharpen seems to be the most viable option. Worth noting: NGit (a .NET port of JGit) is also using Sharpen to do their code generation. They have pretty good documentation about the process. They have developed a bunch of support classes to enable the Sharpen conversion. I was thinking of contacting Lluis (developer of NGit), and seeing if he would be able to help us get our Sharpen setup rolling, or at least help evaluate our use case. Anyhow, check out the project at: https://github.com/slluis/ngit
        Hide
        Alex Thompson added a comment -

        Looks like NGit does the pre/post as patches. I think we can make the pre/post more integrated and generalized by extending sharpen. Their support classes do look useful.

        Show
        Alex Thompson added a comment - Looks like NGit does the pre/post as patches. I think we can make the pre/post more integrated and generalized by extending sharpen. Their support classes do look useful.
        Hide
        Troy Howard added a comment -

        Alex - I was thinking we could fork Sharpen along those lines. AFAIK, Sharpen doesn't accept contributions, and including the source code in our repo would require them to donate to us... So we'd have to do that outside of the ASF. We could bring together both changes to Sharpen to reduce pre/post patches and also create a reusable set of Support classes starting with the ones at NGit.

        Perhaps over time we could convince db4o to merge our fork back in, or donate Sharpen to ASF.

        Show
        Troy Howard added a comment - Alex - I was thinking we could fork Sharpen along those lines. AFAIK, Sharpen doesn't accept contributions, and including the source code in our repo would require them to donate to us... So we'd have to do that outside of the ASF. We could bring together both changes to Sharpen to reduce pre/post patches and also create a reusable set of Support classes starting with the ones at NGit. Perhaps over time we could convince db4o to merge our fork back in, or donate Sharpen to ASF.
        Hide
        Alex Thompson added a comment -

        I saw db40 did accept a patch from an outside user, but it was a pretty small fix. For our more significant changes a fork is probably better so our progress is not dictated by db4o.

        Show
        Alex Thompson added a comment - I saw db40 did accept a patch from an outside user, but it was a pretty small fix. For our more significant changes a fork is probably better so our progress is not dictated by db4o.
        Hide
        Troy Howard added a comment -

        I guess the best thing to do is to put it to a 72 hour vote on the list.

        It would cover, generally, using Sharpen for conversion, and by proxy creating and maintaining a non-ASF fork of Sharpen that our process depends on.

        The ultimate question, of course, is what should we call the fork?

        Show
        Troy Howard added a comment - I guess the best thing to do is to put it to a 72 hour vote on the list. It would cover, generally, using Sharpen for conversion, and by proxy creating and maintaining a non-ASF fork of Sharpen that our process depends on. The ultimate question, of course, is what should we call the fork?
        Hide
        Prescott Nasser added a comment -

        Sharcene, Larpen, Larcene....Lupen!

        Show
        Prescott Nasser added a comment - Sharcene, Larpen, Larcene....Lupen!
        Hide
        Troy Howard added a comment -

        Assigning to Alex to this task (now that I figured out how to add people into the assignee's list).

        Show
        Troy Howard added a comment - Assigning to Alex to this task (now that I figured out how to add people into the assignee's list).
        Hide
        Troy Howard added a comment -

        Regarding forking Sharpen, on second thought, they do seem to have activity on the project. The most recent commit was 2/21/2011, there is an issue tracker, a somewhat active Sharpen user forum, and have accepted outside patches in the not so distant past.

        Forking might not be appropriate unless it's just for the purposes of working on a complex patch. Perhaps we should contact the maintainers at db4o and let them know about our intended use of Sharpen, and see how they feel about getting regular patches from us. Maybe we can streamline the process a bit.

        Show
        Troy Howard added a comment - Regarding forking Sharpen, on second thought, they do seem to have activity on the project. The most recent commit was 2/21/2011, there is an issue tracker, a somewhat active Sharpen user forum, and have accepted outside patches in the not so distant past. Forking might not be appropriate unless it's just for the purposes of working on a complex patch. Perhaps we should contact the maintainers at db4o and let them know about our intended use of Sharpen, and see how they feel about getting regular patches from us. Maybe we can streamline the process a bit.
        Hide
        Alex Thompson added a comment -

        That's worth a shot I guess.
        Forum thread I started:
        http://developer.db4o.com/Forums/tabid/98/aft/10503/Default.aspx

        Show
        Alex Thompson added a comment - That's worth a shot I guess. Forum thread I started: http://developer.db4o.com/Forums/tabid/98/aft/10503/Default.aspx
        Hide
        Alex Thompson added a comment -

        So db4o did get back to me. They would need typical things like contribution agreements and full review control. You can see the response here:
        http://developer.db4o.com/Forums/tabid/98/aft/10503/Default.aspx

        I'm kinda leaning towards a fork but what does everyone think about their constraints?

        Show
        Alex Thompson added a comment - So db4o did get back to me. They would need typical things like contribution agreements and full review control. You can see the response here: http://developer.db4o.com/Forums/tabid/98/aft/10503/Default.aspx I'm kinda leaning towards a fork but what does everyone think about their constraints?
        Hide
        Prescott Nasser added a comment -

        probably have to fork - we'll likely move very quickly at the start for changes. Once we stablize - maybe we can toss it back to them as a patch. We may find we are making changes that they won't accept

        Show
        Prescott Nasser added a comment - probably have to fork - we'll likely move very quickly at the start for changes. Once we stablize - maybe we can toss it back to them as a patch. We may find we are making changes that they won't accept
        Hide
        Scott Lombard added a comment -

        I was investigating what license sharpen uses and found they offer what is called db4o Opensource Compatibility License (dOCL) instead of the GPL (refer to http://www.db4o.com/about/company/legalpolicies/docl.aspx). I read this a possiblity, but I have to admit I don't fully understand all the legal language.

        Show
        Scott Lombard added a comment - I was investigating what license sharpen uses and found they offer what is called db4o Opensource Compatibility License (dOCL) instead of the GPL (refer to http://www.db4o.com/about/company/legalpolicies/docl.aspx ). I read this a possiblity, but I have to admit I don't fully understand all the legal language.
        Hide
        Alex Thompson added a comment -

        The dOCL is just an option in addition to (not instead of) the GPL. From the dOCL page:

        "Versant licenses the Software (as defined in Section 1) pursuant to (1) this Agreement, (2) a commercial, royalty-based license agreement, and (3) the GNU General Public License v2.0 ("GPL"). You may choose to license the Software pursuant to any of the three agreements."

        I think the purpose of the dOCL is to cover the scenario where you are mixing code that is already under another open source license. For our sharpen fork I think we would just keep the whole thing GPL.

        Show
        Alex Thompson added a comment - The dOCL is just an option in addition to (not instead of) the GPL. From the dOCL page: "Versant licenses the Software (as defined in Section 1) pursuant to (1) this Agreement, (2) a commercial, royalty-based license agreement, and (3) the GNU General Public License v2.0 ("GPL"). You may choose to license the Software pursuant to any of the three agreements." I think the purpose of the dOCL is to cover the scenario where you are mixing code that is already under another open source license. For our sharpen fork I think we would just keep the whole thing GPL.
        Hide
        Scott Lombard added a comment -

        I read the dOCL as one of three licensing options. From the dOCL:

        You may obtain copies of the Software by download from the Versant website. Software governed by this Agreement and Software governed by the GPL are obtained from the same source. For this reason, portions of the Software may be flagged as governed by the GPL license. However, the terms under which Versant licenses the Software to you depend on your choice of license, regardless of any GPL notices contained in the Software.

        We are a FLOSS Application:

        4. Free/Libre and Open Source Software Licenses
        Where your FLOSS Application contains software components that were licensed pursuant to one of the FLOSS licenses set forth below ("FLOSS Licenses"), you may distribute such software components subject to that pre-existing FLOSS License.
        ...
        b. Apache Software License, versions 1.0, 1.1, or 2.0

        I don't know if our fork will be Derived Software:

        3. Derivative Works
        For the purpose of this Agreement, software is deemed a derivative work of the Software ("Derivative Work") where it is based on the Software, including without limitation in the following circumstances:
        a. the software is compiled against the Software;
        b. the software contains specific references to the Software;
        c. the software requires the Software to work; or
        d. the software uses the proprietary API to the Software.

        My concerns are more about the requirement to have a project link on the db4o project website and who owns the changes to the sharpen.

        To keep a GPL license we could not include it in the ASF repository. The GPL license is acceptable for using the sharpen fork as build tool for Lucene.Net. So the fork would become a separate project and I think would have to be maintained independently of ASF.

        What do other projects do?

        Show
        Scott Lombard added a comment - I read the dOCL as one of three licensing options. From the dOCL: You may obtain copies of the Software by download from the Versant website. Software governed by this Agreement and Software governed by the GPL are obtained from the same source. For this reason, portions of the Software may be flagged as governed by the GPL license. However, the terms under which Versant licenses the Software to you depend on your choice of license, regardless of any GPL notices contained in the Software. We are a FLOSS Application: 4. Free/Libre and Open Source Software Licenses Where your FLOSS Application contains software components that were licensed pursuant to one of the FLOSS licenses set forth below ("FLOSS Licenses"), you may distribute such software components subject to that pre-existing FLOSS License. ... b. Apache Software License, versions 1.0, 1.1, or 2.0 I don't know if our fork will be Derived Software: 3. Derivative Works For the purpose of this Agreement, software is deemed a derivative work of the Software ("Derivative Work") where it is based on the Software, including without limitation in the following circumstances: a. the software is compiled against the Software; b. the software contains specific references to the Software; c. the software requires the Software to work; or d. the software uses the proprietary API to the Software. My concerns are more about the requirement to have a project link on the db4o project website and who owns the changes to the sharpen. To keep a GPL license we could not include it in the ASF repository. The GPL license is acceptable for using the sharpen fork as build tool for Lucene.Net. So the fork would become a separate project and I think would have to be maintained independently of ASF. What do other projects do?
        Hide
        Alex Thompson added a comment -

        Yes we already knew the fork would be outside ASF and not distributed with Lucene.Net so GPL will work.

        Show
        Alex Thompson added a comment - Yes we already knew the fork would be outside ASF and not distributed with Lucene.Net so GPL will work.
        Hide
        Scott Lombard added a comment -

        Why fork outside of ASF if we can keep it inside? Is a independent project justified? It seems to me there is a lot of infrastructure that needs to be duplicated and maintained.

        I agreed to starting a fork outside of ASF because I didn't think there was any possibility to bring code into lucene.net. Now, I just don't understand licensing well enough to rule out a dOCL license from db4o.

        Show
        Scott Lombard added a comment - Why fork outside of ASF if we can keep it inside? Is a independent project justified? It seems to me there is a lot of infrastructure that needs to be duplicated and maintained. I agreed to starting a fork outside of ASF because I didn't think there was any possibility to bring code into lucene.net. Now, I just don't understand licensing well enough to rule out a dOCL license from db4o.
        Hide
        Alex Thompson added a comment -

        My thoughts on the fork have been to make something that would be useful beyond Lucene, and the scope of the problems seem to be beyond the scope of Lucene.Net, so I do think an independent project would be a more natural fit. And if we used say BitBucket, would the infrastructure really be that much of a barrier?

        Show
        Alex Thompson added a comment - My thoughts on the fork have been to make something that would be useful beyond Lucene, and the scope of the problems seem to be beyond the scope of Lucene.Net, so I do think an independent project would be a more natural fit. And if we used say BitBucket, would the infrastructure really be that much of a barrier?
        Hide
        Prescott Nasser added a comment -

        Keeping it all in the same place has some real positives to me. It makes it all easily 'seeable' to everyone, no going to another project. What if we keep it in our repo and at the appropriate time spin it off into a sub project, or another incubator project?

        I just think for getting started and building momentum it would pay to keep it close.

        Show
        Prescott Nasser added a comment - Keeping it all in the same place has some real positives to me. It makes it all easily 'seeable' to everyone, no going to another project. What if we keep it in our repo and at the appropriate time spin it off into a sub project, or another incubator project? I just think for getting started and building momentum it would pay to keep it close.
        Hide
        Prescott Nasser added a comment -

        I'm assuming we can give it the ASF license? If there are licensing issues, then I think this conversation is moot.

        Show
        Prescott Nasser added a comment - I'm assuming we can give it the ASF license? If there are licensing issues, then I think this conversation is moot.
        Hide
        Alex Thompson added a comment -

        Another question from the dOCL:

        1. Subject
        "Software" means the current version of the db4o database engine software and all patches, bug fixes, error corrections and future versions. Software does not mean add-on packages which are not part of the db4o database engine such as Hibernate or Bloat, which you would license directly from their respective vendors.

        I don't know if sharpen can be considered part of the database engine so can the dOCL even apply?

        Also to put it in our repo wouldn't there need to be a software grant agreement from db4o and any other contributors?
        I don't know if it would be any easier to get started.

        Show
        Alex Thompson added a comment - Another question from the dOCL: 1. Subject "Software" means the current version of the db4o database engine software and all patches, bug fixes, error corrections and future versions. Software does not mean add-on packages which are not part of the db4o database engine such as Hibernate or Bloat, which you would license directly from their respective vendors. I don't know if sharpen can be considered part of the database engine so can the dOCL even apply? Also to put it in our repo wouldn't there need to be a software grant agreement from db4o and any other contributors? I don't know if it would be any easier to get started.
        Hide
        Scott Lombard added a comment -

        My point when starting this is it worth asking the questions to bring the source into our repo. I agree with Prescott that it will be easier to manage as part of the project, atleast to start. I will send a new email out to the dev list and see what people have to say. I feel it is worth investigating and getting all the answers to the unknowns.

        Show
        Scott Lombard added a comment - My point when starting this is it worth asking the questions to bring the source into our repo. I agree with Prescott that it will be easier to manage as part of the project, atleast to start. I will send a new email out to the dev list and see what people have to say. I feel it is worth investigating and getting all the answers to the unknowns.
        Hide
        Prescott Nasser added a comment -

        Sharpen seems to be too simplistic an option for our current needs. We seem to be heading toward a hand converted method to maintain our versions. This gives us better control over the structures we choose to use.

        Show
        Prescott Nasser added a comment - Sharpen seems to be too simplistic an option for our current needs. We seem to be heading toward a hand converted method to maintain our versions. This gives us better control over the structures we choose to use.

          People

          • Assignee:
            Prescott Nasser
            Reporter:
            George Aroush
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Due:
              Created:
              Updated:
              Resolved:

              Development