RE: RE: Vote thread started on gene...@lucene.apache.org
Marco, My feeling would be to create strong automated conversion tools to allow java Lucene to be ported in to .NET in as few steps and as possible. The .net style goal is a noble one, but will require a significant more commitment to the project in the future. As each new version of java Lucene will have to be integrated by hand into the .net version. As the conversion tools get more advanced and robust .net style code may be implemented as part of the automated conversion process. Scott -Original Message- From: Marco Dissel [mailto:marco.dis...@gmail.com] Sent: Thursday, December 30, 2010 1:16 PM To: lucene-net-u...@lucene.apache.org Cc: lucene-net-dev@lucene.apache.org Subject: Re: RE: Vote thread started on gene...@lucene.apache.org What will be the goal of new committors? Convert the source into .net style code? If yes, we should try to stop will all the spin-offs and concentrate all the development in one project. Op 30 dec. 2010 19:02 schreef Lombard, Scott slomb...@kingindustries.com het volgende: Grant, Thanks for your time explaining all the details. I will be willing work on a proposal to put Lucene.Net back in to incubation. I will need other people to step up and be committers as well. Heath has volunteered and as Grant has stated 4 committers are needed to for incubation. Who else is willing to be a committer? Grant I will definitely be taking you up on your offer to help on bring Lucene.Net into incubation. Scott -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Thursday, December 30, 2010 12:32 PM To: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: Hi Grant, Thanks for taking the time to respond. While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. (I guess if I was, I could just use Lucene proper and that would be that) As to other duties of a committer, I think the ASF is perceived as a black box of questions for most of us. For one, I don't think anyone outside the 4 committers even understand *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. Maybe if there was an understanding of the why, the requirements of the ASF would make more sense. I think a lot of us right now just perceive the ASF as the group that is wanting to kill Lucene.net. I don't think we have a desire to kill it, I just think we are faced with the unfortunate reality that the project is already dead and now us on the PMC have the unfortunate job of cleaning up the mess as best we can. Again, it is not even that we want to see it go away, we on the PMC just don't want to be responsible for it's upkeep. You give me the names of 4 people who are willing to be committers (i.e. people willing to volunteer their time) and I will do my best to get the project into the Incubator. However, I have to tell you, my willingness to help is diminishing with every trip we take around this same circle of discussion. Simply put, given the way the vote has gone so far, the Lucene PMC is no longer interested in sustaining this project. If the community wishes to see it live at the ASF then one of you had better step up and spend 20-30 minutes of your time writing up the draft proposal (most of it can be copied and pasted) and circulating it. In fact, given the amount of time some of you have no doubt spent writing on this and other related threads you could have put together the large majority of the proposal, circulated the draft and got other volunteers to help and already be moving forward in a positive direction. Truth be told, I would do it, but I am explicitly not going to because I think that if the community can't take that one step to move forward, then it truly doesn't deserve to. I get your comments about the slower than slow development, but that is also somewhat of a sign that it works. While 2.9.2 may be behind, it seems very stable with very few issues. If we send the project to the attic, how will anyone be able to submit bugfixes ever? Frankly, I use 2.9.2 every day and have not found bugs in the areas that I use... but I'm sure they are in there somewhere. As for the name, I thought Lucene.net was the name of the project back in the SourceForge days... So my question is based on the premise that if the lucene.net name was brought *to* ASF, why can the community not leave with it? Again, IANAL, but just b/c it was improperly used beforehand does not mean it is legally owned by some other entity. The Lucene name has been at the ASF since 2001 and Lucene.NET is also now a part of the ASF. (If your interested, go look at the discussions around iBatis and the movement of that community to MyBatis) -Grant This message (and any associated files) is intended only
Re: Vote thread started on gene...@lucene.apache.org
Scott, I agree with everything you said. My opinion is that one of the largest failings of the current Lucene.Net development effort is that there's too much magic in the conversion process. This is assuming we continue with Lucene.Net as a line-by-line automated port. As Heath said, the details of how we run the project are up to the next group of committers to decide once that group has been established. I'm sure this issue (as well as numerous other issues) will be discussed in great detail and length by the community at that time. Thanks, Troy On Thu, Dec 30, 2010 at 10:57 AM, Lombard, Scott slomb...@kingindustries.com wrote: Troy, My feeling is that a combination Java and .Net experience is needed. Some people will focus on Bug fixes in the .Net code while other focus on the translation of the code as their experience allows. One of the things I would like to see different with Lucene.Net is that the method conversion is kept in the SVN or Wiki. I feel the pre and post processing as well as possibly extensions to what ever tool that is used for the conversion are more important to this project then the actual executed code. Keeping a focus on making strong conversion tools as a community should help reduce the lag between a Java releases to a .Net releases. We then won't be waiting for one person to make the conversion. Scott -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, December 30, 2010 1:38 PM To: lucene-net-u...@lucene.apache.org Cc: lucene-net-dev@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org Scott, I will gladly help put this proposal together and would like to volunteer as a committer. I am communicating with others to find some additional candidates to be committers. Regarding Heath, a quote from his last message in this thread: While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. Thanks, Troy On Thu, Dec 30, 2010 at 10:01 AM, Lombard, Scott slomb...@kingindustries.com wrote: Grant, Thanks for your time explaining all the details. I will be willing work on a proposal to put Lucene.Net back in to incubation. I will need other people to step up and be committers as well. Heath has volunteered and as Grant has stated 4 committers are needed to for incubation. Who else is willing to be a committer? Grant I will definitely be taking you up on your offer to help on bring Lucene.Net into incubation. Scott -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Thursday, December 30, 2010 12:32 PM To: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: Hi Grant, Thanks for taking the time to respond. While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. (I guess if I was, I could just use Lucene proper and that would be that) As to other duties of a committer, I think the ASF is perceived as a black box of questions for most of us. For one, I don't think anyone outside the 4 committers even understand *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. Maybe if there was an understanding of the why, the requirements of the ASF would make more sense. I think a lot of us right now just perceive the ASF as the group that is wanting to kill Lucene.net. I don't think we have a desire to kill it, I just think we are faced with the unfortunate reality that the project is already dead and now us on the PMC have the unfortunate job of cleaning up the mess as best we can. Again, it is not even that we want to see it go away, we on the PMC just don't want to be responsible for it's upkeep. You give me the names of 4 people who are willing to be committers (i.e. people willing to volunteer their time) and I will do my best to get the project into the Incubator. However, I have to tell you, my willingness to help is diminishing with every trip we take around this same circle of discussion. Simply put, given the way the vote has gone so far, the Lucene PMC is no longer interested in sustaining this project. If the community wishes to see it live at the ASF then one of you had better step up and spend 20-30 minutes of your time writing up the draft proposal (most of it can be copied and pasted) and circulating it. In fact, given the amount of time some of you have no doubt spent writing on this and other related threads you could have put together the large majority of the proposal, circulated the draft and got other volunteers to help and already be moving
Re: RE: Vote thread started on gene...@lucene.apache.org
Marco, I agree with you on this front. I feel that the first tasks that a new Lucene.Net team should focus on, in terms of development are: - Fully automating a line-by-line port using a tool such as Sharpen. This needs to become a commodity function requiring very little development effort - Bring the existing forks back in as branches within the ASF project. I am very interested in pursuing continued development on a more .NET style port (i.e. the Lucere project I started or Aimee.Net The Lucene.Net project should be able to continue with both development paths in the same project. Thanks, Troy On Thu, Dec 30, 2010 at 10:15 AM, Marco Dissel marco.dis...@gmail.com wrote: What will be the goal of new committors? Convert the source into .net style code? If yes, we should try to stop will all the spin-offs and concentrate all the development in one project. Op 30 dec. 2010 19:02 schreef Lombard, Scott slomb...@kingindustries.com het volgende: Grant, Thanks for your time explaining all the details. I will be willing work on a proposal to put Lucene.Net back in to incubation. I will need other people to step up and be committers as well. Heath has volunteered and as Grant has stated 4 committers are needed to for incubation. Who else is willing to be a committer? Grant I will definitely be taking you up on your offer to help on bring Lucene.Net into incubation. Scott -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Thursday, December 30, 2010 12:32 PM To: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: Hi Grant, Thanks for taking the time to respond. While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. (I guess if I was, I could just use Lucene proper and that would be that) As to other duties of a committer, I think the ASF is perceived as a black box of questions for most of us. For one, I don't think anyone outside the 4 committers even understand *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. Maybe if there was an understanding of the why, the requirements of the ASF would make more sense. I think a lot of us right now just perceive the ASF as the group that is wanting to kill Lucene.net. I don't think we have a desire to kill it, I just think we are faced with the unfortunate reality that the project is already dead and now us on the PMC have the unfortunate job of cleaning up the mess as best we can. Again, it is not even that we want to see it go away, we on the PMC just don't want to be responsible for it's upkeep. You give me the names of 4 people who are willing to be committers (i.e. people willing to volunteer their time) and I will do my best to get the project into the Incubator. However, I have to tell you, my willingness to help is diminishing with every trip we take around this same circle of discussion. Simply put, given the way the vote has gone so far, the Lucene PMC is no longer interested in sustaining this project. If the community wishes to see it live at the ASF then one of you had better step up and spend 20-30 minutes of your time writing up the draft proposal (most of it can be copied and pasted) and circulating it. In fact, given the amount of time some of you have no doubt spent writing on this and other related threads you could have put together the large majority of the proposal, circulated the draft and got other volunteers to help and already be moving forward in a positive direction. Truth be told, I would do it, but I am explicitly not going to because I think that if the community can't take that one step to move forward, then it truly doesn't deserve to. I get your comments about the slower than slow development, but that is also somewhat of a sign that it works. While 2.9.2 may be behind, it seems very stable with very few issues. If we send the project to the attic, how will anyone be able to submit bugfixes ever? Frankly, I use 2.9.2 every day and have not found bugs in the areas that I use... but I'm sure they are in there somewhere. As for the name, I thought Lucene.net was the name of the project back in the SourceForge days... So my question is based on the premise that if the lucene.net name was brought *to* ASF, why can the community not leave with it? Again, IANAL, but just b/c it was improperly used beforehand does not mean it is legally owned by some other entity. The Lucene name has been at the ASF since 2001 and Lucene.NET is also now a part of the ASF. (If your interested, go look at the discussions around iBatis and the movement of that community to MyBatis) -Grant This message (and any associated files) is intended only for the use of the individual
RE: RE: Vote thread started on gene...@lucene.apache.org
Folks, I will freely admit that I'm seizing the opportunity to raise an old point - but that problem would be non-existent if this was a project that implemented a methodology as opposed to being a continuous port effort. I will even go as far as suggesting that this would broaden (and ease) the recruitment of committers. It almost feels like the goal is not simply to port Lucene.java to Lucene.net but to also develop a technology that ports things automatically. I would almost suggest that this in itself could be an ASF TLP. It still feels to me that everyone is trying to cut the head off a two-headed dragon with a single sword and a single motion. Once search algorithms was discovered and implemented - it should be up to the language-specific programmers to implement these and optimize these as they see fit. Both languages have their strengths and their own frameworks - at the moment the java side has great benefits which in turn greatly hinder the success of the .net side. In a nutshell, while some cultures seem to be better at courtship - the fact that I don't speak some of these languages shouldn't make me less good at it. I think that a project for a Java-NET and NET-Java would be a great idea. Again, it would allow a lot of people that are doing the same for hundreds of other projects to simply pool their efforts. Just my Canadian 2 cents (which is almost at par with the American cents these days) Karell Ste-Marie C.I.O. - BrainBank Inc -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Thursday, December 30, 2010 2:17 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: RE: RE: Vote thread started on gene...@lucene.apache.org Marco, My feeling would be to create strong automated conversion tools to allow java Lucene to be ported in to .NET in as few steps and as possible. The .net style goal is a noble one, but will require a significant more commitment to the project in the future. As each new version of java Lucene will have to be integrated by hand into the .net version. As the conversion tools get more advanced and robust .net style code may be implemented as part of the automated conversion process. Scott
RE: RE: Vote thread started on gene...@lucene.apache.org
From everything that was said it seems apparent to me that the only way for Lucene.Net to stay alive is to move back to incubation. So where do we go from here? More than 4 people have said they are willing to be committers. Is this email list the best place to start working on a proposal, should it be done between a small group offline or is there a way that the community can work on it together? Thoughts? Scott -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, December 30, 2010 2:22 PM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-u...@lucene.apache.org Subject: Re: RE: Vote thread started on gene...@lucene.apache.org Marco, I agree with you on this front. I feel that the first tasks that a new Lucene.Net team should focus on, in terms of development are: - Fully automating a line-by-line port using a tool such as Sharpen. This needs to become a commodity function requiring very little development effort - Bring the existing forks back in as branches within the ASF project. I am very interested in pursuing continued development on a more .NET style port (i.e. the Lucere project I started or Aimee.Net The Lucene.Net project should be able to continue with both development paths in the same project. Thanks, Troy On Thu, Dec 30, 2010 at 10:15 AM, Marco Dissel marco.dis...@gmail.com wrote: What will be the goal of new committors? Convert the source into .net style code? If yes, we should try to stop will all the spin-offs and concentrate all the development in one project. Op 30 dec. 2010 19:02 schreef Lombard, Scott slomb...@kingindustries.com het volgende: Grant, Thanks for your time explaining all the details. I will be willing work on a proposal to put Lucene.Net back in to incubation. I will need other people to step up and be committers as well. Heath has volunteered and as Grant has stated 4 committers are needed to for incubation. Who else is willing to be a committer? Grant I will definitely be taking you up on your offer to help on bring Lucene.Net into incubation. Scott -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Thursday, December 30, 2010 12:32 PM To: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: Hi Grant, Thanks for taking the time to respond. While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. (I guess if I was, I could just use Lucene proper and that would be that) As to other duties of a committer, I think the ASF is perceived as a black box of questions for most of us. For one, I don't think anyone outside the 4 committers even understand *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. Maybe if there was an understanding of the why, the requirements of the ASF would make more sense. I think a lot of us right now just perceive the ASF as the group that is wanting to kill Lucene.net. I don't think we have a desire to kill it, I just think we are faced with the unfortunate reality that the project is already dead and now us on the PMC have the unfortunate job of cleaning up the mess as best we can. Again, it is not even that we want to see it go away, we on the PMC just don't want to be responsible for it's upkeep. You give me the names of 4 people who are willing to be committers (i.e. people willing to volunteer their time) and I will do my best to get the project into the Incubator. However, I have to tell you, my willingness to help is diminishing with every trip we take around this same circle of discussion. Simply put, given the way the vote has gone so far, the Lucene PMC is no longer interested in sustaining this project. If the community wishes to see it live at the ASF then one of you had better step up and spend 20-30 minutes of your time writing up the draft proposal (most of it can be copied and pasted) and circulating it. In fact, given the amount of time some of you have no doubt spent writing on this and other related threads you could have put together the large majority of the proposal, circulated the draft and got other volunteers to help and already be moving forward in a positive direction. Truth be told, I would do it, but I am explicitly not going to because I think that if the community can't take that one step to move forward, then it truly doesn't deserve to. I get your comments about the slower than slow development, but that is also somewhat of a sign that it works. While 2.9.2 may be behind, it seems very stable with very few issues. If we send the project to the attic, how will anyone be able to submit bugfixes ever? Frankly, I use 2.9.2 every day and have not found bugs in the areas that I use... but I'm sure
Re: RE: Vote thread started on gene...@lucene.apache.org
Does the conversion tool actually help or hinder? My feeling is that the more dependency you have on a tool, the less likely this project will ever stand on its own. There should probably be parallelized branches. one that continues using the tool to provide for the current gaps between .net lucene while the other branch that focuses on more .net styled api is moved forward. It also seemed like other volunteers wanted to use Visual Studio 2010, move lucene.net to a more .net friendly api (hopefully adhere a bit better to the ms coding guidelineshttp://blogs.msdn.com/b/brada/archive/2005/01/26/361363.aspxso that figure one's way around the code base is less invovled), and let it evolve. As Grant points out, the biggest problem is getting people to not just discuss the future of lucene.net but actually to step up and get involved working on it. No one should be discarded for their lack of Java or programming knowledge if they have a sincere wish to learn and hours to give to the project. There are more things to be done than just coding or porting java code. They can learn as they go. Does one really need to know Java to write C# test cases? This project seriously lacks visibility, documentation, a decent website, blogging on lucene.net, or any kind of decent PR/Marketing pathway that will help build up the community and move it forward. Any future PMC should be cognizant of that as well as the landscape of .Net opensource and how that is changing of late. The java version has solr (which any language can talk to) built on top of it and can use other projects like tika / poi for indexing. Whats the business value of lucene.net if its line by line port of the lucene version that doesn't have anything extra that its father project already has? Something to think on. - Michael On Thu, Dec 30, 2010 at 2:17 PM, Lombard, Scott slomb...@kingindustries.com wrote: Marco, My feeling would be to create strong automated conversion tools to allow java Lucene to be ported in to .NET in as few steps and as possible. The .net style goal is a noble one, but will require a significant more commitment to the project in the future. As each new version of java Lucene will have to be integrated by hand into the .net version. As the conversion tools get more advanced and robust .net style code may be implemented as part of the automated conversion process. Scott -Original Message- From: Marco Dissel [mailto:marco.dis...@gmail.com] Sent: Thursday, December 30, 2010 1:16 PM To: lucene-net-u...@lucene.apache.org Cc: lucene-net-dev@lucene.apache.org Subject: Re: RE: Vote thread started on gene...@lucene.apache.org What will be the goal of new committors? Convert the source into .net style code? If yes, we should try to stop will all the spin-offs and concentrate all the development in one project. Op 30 dec. 2010 19:02 schreef Lombard, Scott slomb...@kingindustries.com het volgende: Grant, Thanks for your time explaining all the details. I will be willing work on a proposal to put Lucene.Net back in to incubation. I will need other people to step up and be committers as well. Heath has volunteered and as Grant has stated 4 committers are needed to for incubation. Who else is willing to be a committer? Grant I will definitely be taking you up on your offer to help on bring Lucene.Net into incubation. Scott -Original Message- From: Grant Ingersoll [mailto:gsing...@apache.org] Sent: Thursday, December 30, 2010 12:32 PM To: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org On Dec 30, 2010, at 9:51 AM, Heath Aldrich wrote: Hi Grant, Thanks for taking the time to respond. While I have developed extensively against Lucene.net, I do not possess the java skills needed to do a port of the code... So, while I wouldn't mind being a committer, I do not think I am qualified. (I guess if I was, I could just use Lucene proper and that would be that) As to other duties of a committer, I think the ASF is perceived as a black box of questions for most of us. For one, I don't think anyone outside the 4 committers even understand *why* it is a good thing to be on the ASF vs. CodePlex, Sourceforge, etc. Maybe if there was an understanding of the why, the requirements of the ASF would make more sense. I think a lot of us right now just perceive the ASF as the group that is wanting to kill Lucene.net. I don't think we have a desire to kill it, I just think we are faced with the unfortunate reality that the project is already dead and now us on the PMC have the unfortunate job of cleaning up the mess as best we can. Again, it is not even that we want to see it go away, we on the PMC just don't want to be responsible for it's upkeep. You give me the names of 4 people who are willing to be committers (i.e. people willing to volunteer their time) and I will do
Re: Vote thread started on gene...@lucene.apache.org
That is exactly what I would suggest. Sharpen looks like a great tool, since you can customize it's behaviour. In fact, the only downside is that you have to customize it's behaviour which requires a lot of upfront work. Thanks, Troy On Thu, Dec 30, 2010 at 11:42 AM, Prescott Nasser geobmx...@hotmail.com wrote: Maybe I'm misunderstanding you, but I think the technology is there - no generic porting tool will be 100%, it will always require pre/post processing. Sharpen is a pretty good generic conversion tool. I agree in that I think we need to focus on a process utilizing a tool such as sharpen and developing the pre/post processing clean up scripts that are specific to Lucene. ~Prescott Subject: RE: RE: Vote thread started on gene...@lucene.apache.org Date: Thu, 30 Dec 2010 14:29:21 -0500 From: stema...@brain-bank.com To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Folks, I will freely admit that I'm seizing the opportunity to raise an old point - but that problem would be non-existent if this was a project that implemented a methodology as opposed to being a continuous port effort. I will even go as far as suggesting that this would broaden (and ease) the recruitment of committers. It almost feels like the goal is not simply to port Lucene.java to Lucene.net but to also develop a technology that ports things automatically. I would almost suggest that this in itself could be an ASF TLP. It still feels to me that everyone is trying to cut the head off a two-headed dragon with a single sword and a single motion. Once search algorithms was discovered and implemented - it should be up to the language-specific programmers to implement these and optimize these as they see fit. Both languages have their strengths and their own frameworks - at the moment the java side has great benefits which in turn greatly hinder the success of the .net side. In a nutshell, while some cultures seem to be better at courtship - the fact that I don't speak some of these languages shouldn't make me less good at it. I think that a project for a Java-NET and NET-Java would be a great idea. Again, it would allow a lot of people that are doing the same for hundreds of other projects to simply pool their efforts. Just my Canadian 2 cents (which is almost at par with the American cents these days) Karell Ste-Marie C.I.O. - BrainBank Inc -Original Message- From: Lombard, Scott [mailto:slomb...@kingindustries.com] Sent: Thursday, December 30, 2010 2:17 PM To: lucene-net-dev@lucene.apache.org; lucene-net-u...@lucene.apache.org Subject: RE: RE: Vote thread started on gene...@lucene.apache.org Marco, My feeling would be to create strong automated conversion tools to allow java Lucene to be ported in to .NET in as few steps and as possible. The .net style goal is a noble one, but will require a significant more commitment to the project in the future. As each new version of java Lucene will have to be integrated by hand into the .net version. As the conversion tools get more advanced and robust .net style code may be implemented as part of the automated conversion process. Scott
RE: Vote thread started on gene...@lucene.apache.org
I think it took be 5 deletes of this e-mail and complete rewrites to try to say this in the best way possible: First off, Sharpen is a java tool (from the db4o SVN I found) - using sharpen to port lucene to .net means that people now have to install a jvm on their computers in order to contribute. While this may seem like it makes perfect sense in fact it is this type of requirements that scares pure .net developers away. You cannot ask someone to install a bunch of tools outside of their comfort zone in order to create a tool that works in their world. Furthermore, it's also saying that now - not only do contributors need to know java and have a jvm, but then they also need to know sharpen in order to make a c# product. Gentlemen, I would gladly contribute - I can assure you that I wouldn't be the best but I would be happy to lend a hand - but speaking strictly for myself I don't see myself learning 2-3 new pieces of technologies when I feel that I should just be a good c# programmer to help out. Would it not make more sense, given the fact that we want to reduce work and make a quality product that we become more selective about *what* goes through Sharpen and what can be hand-crafted? IE: Do we really need to port the Java methods of writing to files and handling Threading? What about WCF? Karell Ste-Marie C.I.O. - BrainBank Inc -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, December 30, 2010 2:46 PM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org That is exactly what I would suggest. Sharpen looks like a great tool, since you can customize it's behaviour. In fact, the only downside is that you have to customize it's behaviour which requires a lot of upfront work. Thanks, Troy On Thu, Dec 30, 2010 at 11:42 AM, Prescott Nasser geobmx...@hotmail.com wrote: Maybe I'm misunderstanding you, but I think the technology is there - no generic porting tool will be 100%, it will always require pre/post processing. Sharpen is a pretty good generic conversion tool. I agree in that I think we need to focus on a process utilizing a tool such as sharpen and developing the pre/post processing clean up scripts that are specific to Lucene. ~Prescott
Re: Vote thread started on gene...@lucene.apache.org
Troy, et al, Given the recent positive shift in attitude regarding the Lucene.Net project, I would like to consider ways that I could help contribute as well. As with other people in the community, while my company is very small (I am both Chief Software Architect and Chief Bottle Washer), we do a have a vested interest in seeing this project succeed. One thing to consider while developing the incubator proposal is that the reason I stopped attempting to contribute was that very early on it was made very clear to me that this project was a one-man show and that any efforts I offered towards working on the port were not welcome. I think that in order to succeed the new proposal needs to embrace transparency in the entire port, testing and fix process so that more people (and potential committers) can have the opportunity to get their hands dirty and expect that their ideas will not be rejected out of hand. I'm not saying that everyone should be a committer but rather I would hope that the committers would at least consider input and help from the community. It's important to remember that Lucene.Net is "just" a (very good) line-by-line port*. This means that the skill set we need from committers is very different than what the Lucene Java project would be looking for. I agree with various people who have raised the good point that automation is the way to go for the initial pass. There are now multiple OSS Java-.NET conversion tools out there that while not perfect could offer a good starting point. The strength of working to customize scripts or even the tools themselves would be a repeatable and documented porting process that could be executed in parallel by multiple people with the expectation of deterministic results. Sharpen (db40): http://developer.db4o.com/Blogs/Product/tabid/167/entryid/94/Default.aspx Java 2 CSharp (ILOG/IBM): http://sourceforge.net/apps/mediawiki/j2cstranslator/index.php?title=Main_Page * Various spin-offs are embracing a functional port model but this is not what I am looking for and I get the feeling that some developers would prefer to stick with a "true" port as well. Also remember that we would need not only people to work on the porting mechanism and port but also people willing to develop and run the unit tests and such. In summary, I believe that if we can agree as a community to get away from this magic one-man black-box porting model then more people such as myself would come out of the woodwork and help out. My way is not the only way but it does represent my personal thoughts in any case. Thanks for your consideration, Ben Martz Troy Howard December 30, 2010 11:51 AM Scott, We should communicate on the public list as much as possible. I'll put together the draft proposal today, post it here, and ask for feedback from both the Lucene PMC and the community. We will wait over the weekend and Monday to allow people who might have additional input the opportunity to either see this at home or at work. On Tuesday (Jan 4th) we will move forward with whatever our best effort has produced and go from there. Thanks, Troy
Re: Vote thread started on gene...@lucene.apache.org
It's my opinion that we can basically commoditize an automated port which will fulfill the needs of the community, and allow the project to, at minimum, continue to release, in a timely fashion, direct ports of the Java Lucene releases... Meanwhile we can continue the efforts represented in Lucere, Lucille, and Aimee.Net to create an alternative API for Lucene.Net which may or may not include completely re-written code, depending on the specifics. I think both concepts can co-exist in a single project and that this will be the best way to move forward. If you followed the Lucere project, you'll see that my approach with TDD and Contract Driven Design was intended to facilitate just such an arrangement. Thanks, Troy On Thu, Dec 30, 2010 at 12:32 PM, Prescott Nasser geobmx...@hotmail.com wrote: In incubator we can probably rewrite the description of the project - but in the past we were pushed from doing anything but a straight port becuase the description of the project was line by line port - where a tool makes sense, and .NET specific contructs are basically avoided becuase that wouldn't be a line by line port. We talked about using things like Enums but we were shot down from this idea by someone... I agree with you whole heartly about utilizing sharpen and jvm just to port the code. The Lucere project was the idea of rewriting the java code to .Net, using standard constructs. I think the goal for the ASF project was to minimize work needed to be done to upgrade to new java things that come out. If we purse this direction, then every change needs to be manually ported. I've already said I think that is do-able once we are on part with the latest java. ~Prescott Nasser prescott.nas...@hotmail.com 650.208.4205 Subject: RE: Vote thread started on gene...@lucene.apache.org Date: Thu, 30 Dec 2010 15:24:32 -0500 From: stema...@brain-bank.com To: lucene-net-dev@lucene.apache.org CC: lucene-net-u...@lucene.apache.org I think it took be 5 deletes of this e-mail and complete rewrites to try to say this in the best way possible: First off, Sharpen is a java tool (from the db4o SVN I found) - using sharpen to port lucene to .net means that people now have to install a jvm on their computers in order to contribute. While this may seem like it makes perfect sense in fact it is this type of requirements that scares pure .net developers away. You cannot ask someone to install a bunch of tools outside of their comfort zone in order to create a tool that works in their world. Furthermore, it's also saying that now - not only do contributors need to know java and have a jvm, but then they also need to know sharpen in order to make a c# product. Gentlemen, I would gladly contribute - I can assure you that I wouldn't be the best but I would be happy to lend a hand - but speaking strictly for myself I don't see myself learning 2-3 new pieces of technologies when I feel that I should just be a good c# programmer to help out. Would it not make more sense, given the fact that we want to reduce work and make a quality product that we become more selective about *what* goes through Sharpen and what can be hand-crafted? IE: Do we really need to port the Java methods of writing to files and handling Threading? What about WCF? Karell Ste-Marie C.I.O. - BrainBank Inc -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Thursday, December 30, 2010 2:46 PM To: lucene-net-dev@lucene.apache.org Cc: lucene-net-u...@lucene.apache.org Subject: Re: Vote thread started on gene...@lucene.apache.org That is exactly what I would suggest. Sharpen looks like a great tool, since you can customize it's behaviour. In fact, the only downside is that you have to customize it's behaviour which requires a lot of upfront work. Thanks, Troy On Thu, Dec 30, 2010 at 11:42 AM, Prescott Nasser geobmx...@hotmail.com wrote: Maybe I'm misunderstanding you, but I think the technology is there - no generic porting tool will be 100%, it will always require pre/post processing. Sharpen is a pretty good generic conversion tool. I agree in that I think we need to focus on a process utilizing a tool such as sharpen and developing the pre/post processing clean up scripts that are specific to Lucene. ~Prescott
Re: Vote thread started on gene...@lucene.apache.org
So perhaps the proposal should allow for a combination of a mostly automated baseline line-by-line port and the explicit provision that embraces drop-in (API compliant) .NET-specific replacements for specific classes? - Ben Troy Howard December 30, 2010 12:39 PM It's my opinion that we can basically commoditize an automated port which will fulfill the needs of the community, and allow the project to, at minimum, continue to release, in a timely fashion, direct ports of the Java Lucene releases... Meanwhile we can continue the efforts represented in Lucere, Lucille, and Aimee.Net to create an alternative API for Lucene.Net which may or may not include completely re-written code, depending on the specifics. I think both concepts can co-exist in a single project and that this will be the best way to move forward. If you followed the Lucere project, you'll see that my approach with TDD and Contract Driven Design was intended to facilitate just such an arrangement. Thanks, Troy
Re: Vote thread started on gene...@lucene.apache.org
Yes. I'm in the process of writing that proposal at this time. It will include language in the project description that express our intent to develop a C#/.NET idiomatic version of the library. Please find the in-progress draft version at: http://wiki.apache.org/incubator/Lucene.Net%20Proposal Thanks, Troy On Thu, Dec 30, 2010 at 12:43 PM, Ben Martz benma...@gmail.com wrote: So perhaps the proposal should allow for a combination of a mostly automated baseline line-by-line port and the explicit provision that embraces drop-in (API compliant) .NET-specific replacements for specific classes? - Ben -- Troy Howard thowar...@gmail.com December 30, 2010 12:39 PM It's my opinion that we can basically commoditize an automated port which will fulfill the needs of the community, and allow the project to, at minimum, continue to release, in a timely fashion, direct ports of the Java Lucene releases... Meanwhile we can continue the efforts represented in Lucere, Lucille, and Aimee.Net to create an alternative API for Lucene.Net which may or may not include completely re-written code, depending on the specifics. I think both concepts can co-exist in a single project and that this will be the best way to move forward. If you followed the Lucere project, you'll see that my approach with TDD and Contract Driven Design was intended to facilitate just such an arrangement. Thanks, Troy
