You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by runenur <ru...@gmail.com> on 2009/07/24 13:07:22 UTC
Considering to contribute
Hey,
I've been playing with Lucene.Net for a while, and there are some issues
that I have noticed. First of all, it is very clear from the API that it is
a more or less direct port of Lucene, and does not really feel .NET-ish.
Also, I've noticed that it usually takes a while for a new Lucene release to
get ported to Lucene.Net. For that reason, I am considering to offer some of
my time to help keeping the code base up to date and to follow the .NET
design guidelines in a better manner. In that regard, I have a few questions
I would love if someone could answer:
* Does the code following a coding convention of some kind? For example,
I've noticed that tabbed and spaced tabs are used intermixed, leaving me to
believe that might not be the case.
* Do there exist a prioritized list of what should or could be done to the
code base?
* How far along is the 2.4.x port?
With best regards,
runenur
Re: Considering to contribute
Posted by runenur <ru...@gmail.com>.
Hey guys,
I haven't received any response yet, so I guess I can try to take some
initiative and see how that goes:
My first proposed change is regarding to namespace imports and fully
qualified names. I've notived that fully qualified names are being
used alot, and in my opinion, they clutter the code, and make the code
harder to read. Making better use of the 'using' directive is a task
that can be automated by the use of various tools, one of which is
ReSharper. I've already used this tool to update the code (revision
799135) to remove fully qualified names and use the 'using' directive
instead- It also removed quite a few unused namespace imports. This
change reduced the number of code warnings given by ReSharper
considerably, and this actually helped me spot a couple of bugs in the
code (I'm currently located at another computer and do not remember
the details behind the bugs, but I will bring them to attention at a
later time).
Is this patch something you would be interested in applying?
PS: I have noticed that trunk has started to show signs of the 2.4.0
conversion, which is good news. Nice work!
runenur
On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
> Hey,
> I've been playing with Lucene.Net for a while, and there are some issues
> that I have noticed. First of all, it is very clear from the API that it is
> a more or less direct port of Lucene, and does not really feel .NET-ish.
> Also, I've noticed that it usually takes a while for a new Lucene release to
> get ported to Lucene.Net. For that reason, I am considering to offer some of
> my time to help keeping the code base up to date and to follow the .NET
> design guidelines in a better manner. In that regard, I have a few questions
> I would love if someone could answer:
> * Does the code following a coding convention of some kind? For example,
> I've noticed that tabbed and spaced tabs are used intermixed, leaving me to
> believe that might not be the case.
> * Do there exist a prioritized list of what should or could be done to the
> code base?
> * How far along is the 2.4.x port?
> With best regards,
> runenur
Re: Considering to contribute
Posted by Doug Sale <do...@gmail.com>.
This sounds like a good idea to me. Please create a JIRA entry for this.
On Fri, Jul 31, 2009 at 9:17 AM, Andrei Alecu<an...@tachyon-labs.com> wrote:
> One thing I'd like to see in a future version is the implementation of
> IDisposable on the classes that have a .Close().
>
> I already have some helper classes in a LuceneExtender project I made, such
> as:
>
> public class DisposableIndexWriter : IndexWriter, IDisposable
> {
> ...constructors...
>
> public void Dispose()
> {
> base.Close();
> }
> }
>
> So I can then do this:
>
> using (var writer = new DisposableIndexWriter(IndexDirectory, new
> PorterStemmerAnalyzer()))
> {
> ..update index..
> }
>
> But this should be implemented in the base directly. It's a very small
> diversion from the Java code base but a sensible improvement.
>
>
>
>
>
>
>
> George Aroush wrote:
>>
>> Hi Rune,
>>
>> Be very carefully with any enhancement change you make or propose, they
>> won't be welcome. The goal is to keep deltas between previous ports as
>> small as possible so that subsequent ports can be managed.
>>
>> Do a search in the archive for a background about how a port is done. I
>> documented it.
>>
>> As for how you can contribute, and this is for everyone who asked, please
>> grab the current code off the trunk and use it. Check the NUnit results,
>> and see what if anything fails for you, and work on them. Check "contrib"
>> and port over existing projects or new once.
>>
>> Regards,
>>
>> -- George
>>
>> -----Original Message-----
>> From: Rune Vistnes [mailto:rune.vistnes@gmail.com] Sent: Thursday, July
>> 30, 2009 6:49 PM
>> To: lucene-net-dev@incubator.apache.org
>> Subject: Re: Considering to contribute
>>
>> Hey guys,
>>
>> I haven't received any response yet, so I guess I can try to take some
>> initiative and see how that goes:
>>
>> My first proposed change is regarding to namespace imports and fully
>> qualified names. I've notived that fully qualified names are being
>> used alot, and in my opinion, they clutter the code, and make the code
>> harder to read. Making better use of the 'using' directive is a task
>> that can be automated by the use of various tools, one of which is
>> ReSharper. I've already used this tool to update the code (revision
>> 799135) to remove fully qualified names and use the 'using' directive
>> instead- It also removed quite a few unused namespace imports. This
>> change reduced the number of code warnings given by ReSharper
>> considerably, and this actually helped me spot a couple of bugs in the
>> code (I'm currently located at another computer and do not remember
>> the details behind the bugs, but I will bring them to attention at a
>> later time).
>>
>> Is this patch something you would be interested in applying?
>>
>> PS: I have noticed that trunk has started to show signs of the 2.4.0
>> conversion, which is good news. Nice work!
>>
>> runenur
>>
>> On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
>>
>>>
>>> Hey,
>>> I've been playing with Lucene.Net for a while, and there are some issues
>>> that I have noticed. First of all, it is very clear from the API that it
>>>
>>
>> is
>>
>>>
>>> a more or less direct port of Lucene, and does not really feel .NET-ish.
>>> Also, I've noticed that it usually takes a while for a new Lucene release
>>>
>>
>> to
>>
>>>
>>> get ported to Lucene.Net. For that reason, I am considering to offer some
>>>
>>
>> of
>>
>>>
>>> my time to help keeping the code base up to date and to follow the .NET
>>> design guidelines in a better manner. In that regard, I have a few
>>>
>>
>> questions
>>
>>>
>>> I would love if someone could answer:
>>> * Does the code following a coding convention of some kind? For example,
>>> I've noticed that tabbed and spaced tabs are used intermixed, leaving me
>>>
>>
>> to
>>
>>>
>>> believe that might not be the case.
>>> * Do there exist a prioritized list of what should or could be done to
>>> the
>>> code base?
>>> * How far along is the 2.4.x port?
>>> With best regards,
>>> runenur
>>>
>>
>>
>>
>
>
Re: Considering to contribute
Posted by Andrei Alecu <an...@tachyon-labs.com>.
One thing I'd like to see in a future version is the implementation of
IDisposable on the classes that have a .Close().
I already have some helper classes in a LuceneExtender project I made,
such as:
public class DisposableIndexWriter : IndexWriter, IDisposable
{
...constructors...
public void Dispose()
{
base.Close();
}
}
So I can then do this:
using (var writer = new DisposableIndexWriter(IndexDirectory, new
PorterStemmerAnalyzer()))
{
..update index..
}
But this should be implemented in the base directly. It's a very small
diversion from the Java code base but a sensible improvement.
George Aroush wrote:
> Hi Rune,
>
> Be very carefully with any enhancement change you make or propose, they
> won't be welcome. The goal is to keep deltas between previous ports as
> small as possible so that subsequent ports can be managed.
>
> Do a search in the archive for a background about how a port is done. I
> documented it.
>
> As for how you can contribute, and this is for everyone who asked, please
> grab the current code off the trunk and use it. Check the NUnit results,
> and see what if anything fails for you, and work on them. Check "contrib"
> and port over existing projects or new once.
>
> Regards,
>
> -- George
>
> -----Original Message-----
> From: Rune Vistnes [mailto:rune.vistnes@gmail.com]
> Sent: Thursday, July 30, 2009 6:49 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Considering to contribute
>
> Hey guys,
>
> I haven't received any response yet, so I guess I can try to take some
> initiative and see how that goes:
>
> My first proposed change is regarding to namespace imports and fully
> qualified names. I've notived that fully qualified names are being
> used alot, and in my opinion, they clutter the code, and make the code
> harder to read. Making better use of the 'using' directive is a task
> that can be automated by the use of various tools, one of which is
> ReSharper. I've already used this tool to update the code (revision
> 799135) to remove fully qualified names and use the 'using' directive
> instead- It also removed quite a few unused namespace imports. This
> change reduced the number of code warnings given by ReSharper
> considerably, and this actually helped me spot a couple of bugs in the
> code (I'm currently located at another computer and do not remember
> the details behind the bugs, but I will bring them to attention at a
> later time).
>
> Is this patch something you would be interested in applying?
>
> PS: I have noticed that trunk has started to show signs of the 2.4.0
> conversion, which is good news. Nice work!
>
> runenur
>
> On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
>
>> Hey,
>> I've been playing with Lucene.Net for a while, and there are some issues
>> that I have noticed. First of all, it is very clear from the API that it
>>
> is
>
>> a more or less direct port of Lucene, and does not really feel .NET-ish.
>> Also, I've noticed that it usually takes a while for a new Lucene release
>>
> to
>
>> get ported to Lucene.Net. For that reason, I am considering to offer some
>>
> of
>
>> my time to help keeping the code base up to date and to follow the .NET
>> design guidelines in a better manner. In that regard, I have a few
>>
> questions
>
>> I would love if someone could answer:
>> * Does the code following a coding convention of some kind? For example,
>> I've noticed that tabbed and spaced tabs are used intermixed, leaving me
>>
> to
>
>> believe that might not be the case.
>> * Do there exist a prioritized list of what should or could be done to the
>> code base?
>> * How far along is the 2.4.x port?
>> With best regards,
>> runenur
>>
>
>
>
Re: Considering to contribute
Posted by runenur <ru...@gmail.com>.
Hey George,
As far as I can see, the enhancements I have in mind shouldn't make it
harder to manage subsequent ports. I fact, I believe they would
actually make it easier. For example, not using fully qualified names
will remove redundancies in the code and result in less code to
manage. The initial 2.4.0 port already contains these kind of changes,
where "System.Object" has been changed to "object". My patch would
make take this a step further and make it consistens across the code
base. Consistency should make the code base more maintainable, not
less.
Another suggestion is to make use of a continous integration (CI)
server. I've had great success with the introduction of one such tool
at work, namely TeamCity. CodeBetter have set up a public instance for
open source projects located at http://teamcity.codebetter.com/, and
well known projects such as NHibernate, Ninject, and Structure Map
have already been added. Using such a CI server, a build can be made
every time code has been commit, the test suite can be run, and emails
can be sent to the mailing list when build errors or errors in a test
run occur.
runenur
On Fri, Jul 31, 2009 at 4:17 AM, George Aroush<ge...@aroush.net> wrote:
> Hi Rune,
>
> Be very carefully with any enhancement change you make or propose, they
> won't be welcome. The goal is to keep deltas between previous ports as
> small as possible so that subsequent ports can be managed.
>
> Do a search in the archive for a background about how a port is done. I
> documented it.
>
> As for how you can contribute, and this is for everyone who asked, please
> grab the current code off the trunk and use it. Check the NUnit results,
> and see what if anything fails for you, and work on them. Check "contrib"
> and port over existing projects or new once.
>
> Regards,
>
> -- George
>
> -----Original Message-----
> From: Rune Vistnes [mailto:rune.vistnes@gmail.com]
> Sent: Thursday, July 30, 2009 6:49 PM
> To: lucene-net-dev@incubator.apache.org
> Subject: Re: Considering to contribute
>
> Hey guys,
>
> I haven't received any response yet, so I guess I can try to take some
> initiative and see how that goes:
>
> My first proposed change is regarding to namespace imports and fully
> qualified names. I've notived that fully qualified names are being
> used alot, and in my opinion, they clutter the code, and make the code
> harder to read. Making better use of the 'using' directive is a task
> that can be automated by the use of various tools, one of which is
> ReSharper. I've already used this tool to update the code (revision
> 799135) to remove fully qualified names and use the 'using' directive
> instead- It also removed quite a few unused namespace imports. This
> change reduced the number of code warnings given by ReSharper
> considerably, and this actually helped me spot a couple of bugs in the
> code (I'm currently located at another computer and do not remember
> the details behind the bugs, but I will bring them to attention at a
> later time).
>
> Is this patch something you would be interested in applying?
>
> PS: I have noticed that trunk has started to show signs of the 2.4.0
> conversion, which is good news. Nice work!
>
> runenur
>
> On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
>> Hey,
>> I've been playing with Lucene.Net for a while, and there are some issues
>> that I have noticed. First of all, it is very clear from the API that it
> is
>> a more or less direct port of Lucene, and does not really feel .NET-ish.
>> Also, I've noticed that it usually takes a while for a new Lucene release
> to
>> get ported to Lucene.Net. For that reason, I am considering to offer some
> of
>> my time to help keeping the code base up to date and to follow the .NET
>> design guidelines in a better manner. In that regard, I have a few
> questions
>> I would love if someone could answer:
>> * Does the code following a coding convention of some kind? For example,
>> I've noticed that tabbed and spaced tabs are used intermixed, leaving me
> to
>> believe that might not be the case.
>> * Do there exist a prioritized list of what should or could be done to the
>> code base?
>> * How far along is the 2.4.x port?
>> With best regards,
>> runenur
>
>
RE: Considering to contribute
Posted by George Aroush <ge...@aroush.net>.
Hi Rune,
Be very carefully with any enhancement change you make or propose, they
won't be welcome. The goal is to keep deltas between previous ports as
small as possible so that subsequent ports can be managed.
Do a search in the archive for a background about how a port is done. I
documented it.
As for how you can contribute, and this is for everyone who asked, please
grab the current code off the trunk and use it. Check the NUnit results,
and see what if anything fails for you, and work on them. Check "contrib"
and port over existing projects or new once.
Regards,
-- George
-----Original Message-----
From: Rune Vistnes [mailto:rune.vistnes@gmail.com]
Sent: Thursday, July 30, 2009 6:49 PM
To: lucene-net-dev@incubator.apache.org
Subject: Re: Considering to contribute
Hey guys,
I haven't received any response yet, so I guess I can try to take some
initiative and see how that goes:
My first proposed change is regarding to namespace imports and fully
qualified names. I've notived that fully qualified names are being
used alot, and in my opinion, they clutter the code, and make the code
harder to read. Making better use of the 'using' directive is a task
that can be automated by the use of various tools, one of which is
ReSharper. I've already used this tool to update the code (revision
799135) to remove fully qualified names and use the 'using' directive
instead- It also removed quite a few unused namespace imports. This
change reduced the number of code warnings given by ReSharper
considerably, and this actually helped me spot a couple of bugs in the
code (I'm currently located at another computer and do not remember
the details behind the bugs, but I will bring them to attention at a
later time).
Is this patch something you would be interested in applying?
PS: I have noticed that trunk has started to show signs of the 2.4.0
conversion, which is good news. Nice work!
runenur
On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
> Hey,
> I've been playing with Lucene.Net for a while, and there are some issues
> that I have noticed. First of all, it is very clear from the API that it
is
> a more or less direct port of Lucene, and does not really feel .NET-ish.
> Also, I've noticed that it usually takes a while for a new Lucene release
to
> get ported to Lucene.Net. For that reason, I am considering to offer some
of
> my time to help keeping the code base up to date and to follow the .NET
> design guidelines in a better manner. In that regard, I have a few
questions
> I would love if someone could answer:
> * Does the code following a coding convention of some kind? For example,
> I've noticed that tabbed and spaced tabs are used intermixed, leaving me
to
> believe that might not be the case.
> * Do there exist a prioritized list of what should or could be done to the
> code base?
> * How far along is the 2.4.x port?
> With best regards,
> runenur
Re: Considering to contribute
Posted by Rune Vistnes <ru...@gmail.com>.
Hey guys,
I haven't received any response yet, so I guess I can try to take some
initiative and see how that goes:
My first proposed change is regarding to namespace imports and fully
qualified names. I've notived that fully qualified names are being
used alot, and in my opinion, they clutter the code, and make the code
harder to read. Making better use of the 'using' directive is a task
that can be automated by the use of various tools, one of which is
ReSharper. I've already used this tool to update the code (revision
799135) to remove fully qualified names and use the 'using' directive
instead- It also removed quite a few unused namespace imports. This
change reduced the number of code warnings given by ReSharper
considerably, and this actually helped me spot a couple of bugs in the
code (I'm currently located at another computer and do not remember
the details behind the bugs, but I will bring them to attention at a
later time).
Is this patch something you would be interested in applying?
PS: I have noticed that trunk has started to show signs of the 2.4.0
conversion, which is good news. Nice work!
runenur
On Fri, Jul 24, 2009 at 1:07 PM, runenur<ru...@gmail.com> wrote:
> Hey,
> I've been playing with Lucene.Net for a while, and there are some issues
> that I have noticed. First of all, it is very clear from the API that it is
> a more or less direct port of Lucene, and does not really feel .NET-ish.
> Also, I've noticed that it usually takes a while for a new Lucene release to
> get ported to Lucene.Net. For that reason, I am considering to offer some of
> my time to help keeping the code base up to date and to follow the .NET
> design guidelines in a better manner. In that regard, I have a few questions
> I would love if someone could answer:
> * Does the code following a coding convention of some kind? For example,
> I've noticed that tabbed and spaced tabs are used intermixed, leaving me to
> believe that might not be the case.
> * Do there exist a prioritized list of what should or could be done to the
> code base?
> * How far along is the 2.4.x port?
> With best regards,
> runenur