lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ciaran Roarty" <ciaran.roa...@gmail.com>
Subject Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
Date Thu, 05 Apr 2007 15:33:51 GMT
Erik et al

I'll look into this over the weekend and workout how to get involved.

Have a good holiday weekend,
Ciaran


On 04/04/07, Erik Hatcher <erik@ehatchersolutions.com> wrote:
>
> Ciaran,
>
> The first step is to contribute some code as a patch (or full code
> dump) to an issue in our issue tracker.
>
> Here's a good overview of the roles we use on Apache projects:
>
>        <http://apache.org/foundation/how-it-works.html#roles>
>
> "developer" is the next step up, and when that role has solidified in
> the community "committer" is considered.
>
>   Erik
>
>
> On Apr 4, 2007, at 4:28 AM, Ciaran Roarty wrote:
>
> > George
> >
> > I think this would be best done on Lucene.Net 2.1 as this will
> > allow us to
> > see the impact of fixes to the 2.1 codebase on the branched code.
> >
> > Now, how do I go about getting a branch?
> >
> > Ciaran
> >
> >
> > On 03/04/07, George Aroush <george@aroush.net> wrote:
> >>
> >> Erik: I agree with your suggestion and I don't think any one is
> >> stiffing
> >> any
> >> innovation.  I'm questioning the value and if this is the right
> >> time to do
> >> this.  At this point, it makes better sense to use our cycles on
> >> brining
> >> the
> >> code base in par with Java's code base.
> >>
> >> Ciaran: If you want to give this a try, go ahead.  You can start
> >> now with
> >> the existing Lucene.Net 2.0 or wait a bit more for 2.1 release and
> >> report
> >> back about your effort.  IMHO, I believe, while you do this
> >> change, the
> >> existing public interfaces of Lucene.Net will end up changing too and
> >> those
> >> changes will have ripple effect all over the code base; but I like
> >> to be
> >> proven otherwise and your experiment might put us on a new track.
> >> So go
> >> for
> >> it!
> >>
> >> -- George
> >>
> >> > -----Original Message-----
> >> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> >> > Sent: Tuesday, April 03, 2007 4:58 PM
> >> > To: lucene-net-dev@incubator.apache.org
> >> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project involvement']
> >> >
> >> > The best way to move forward from here is with actual code
> >> > that demonstrates the benefits.  What I don't like seeing is
> >> > the impression that innovation is being stifled.  If folks
> >> > have great ideas, let's see 'em.  While George is the
> >> > initiator of Lucene.Net, the community owns it.  I'm happy to
> >> > see several folks speak up here about their interest in
> >> > personally helping this project along.  This is exactly what
> >> > it needs.  The more the merrier!
> >> >
> >> > Having a branch that is innovating with more hand-made C#
> >> > sounds great to me.  The comparisons and contrasts between
> >> > the two approaches becomes more concrete, allowing objective
> >> > decisions based on some benchmarking and other factors.
> >> >
> >> >       Erik
> >> >
> >> >
> >> >
> >> > On Apr 3, 2007, at 4:09 PM, Michael Garski wrote:
> >> >
> >> > > Hi Everyone,
> >> > >
> >> > > I am going to have to side with George on this one.  Up to this
> >> > > point I believe he has been the sole contributor &
> >> > committer to the
> >> > > Lucene.Net project, and has been porting over the code once the
> >> > > Java group released a version.  Attempting to exploit the
> >> > > advantages in the .NET framework and continuing to release
> >> > > Lucene.Net in that manner will require lots of repetitive work.
> >> > > Once we can maintain the Lucene.Net trunk identical to the Java
> >> > > trunk (within a day or two), then we can safely start altering
> >> > > internal implementations to take full advantage of the .NET
> >> > > platform and not fall out of step with the API or
> >> functionality of
> >> > > Java Lucene.
> >> > >
> >> > > Of those that are interested in development of Lucene, I highly
> >> > > suggest subscribing to the Java Developer mailing list to see
> >> what
> >> > > changes are being suggested and made.  Incorporating those
> >> changes
> >> > > manually on the .NET side in a relatively short period after they
> >> > > are committed on the Java side will take additional people.  I
> >> for
> >> > > one am interested in this as I have the luxury of being able to
> >> > > contribute during my normal work day.
> >> > >
> >> > > While I do agree that everyone will benefit from changes that
> >> > > exploit the differences in the .NET framework, we'll need to
> >> start
> >> > > with a smaller, more reasonable goal.  Has anyone thought
> >> > of how we
> >> > > can actually maintain a manual port that is reflective of the
> >> > > current Java trunk?  My first thought is that a changelog
> >> > will need
> >> > > to be kept in each class file indicating which Java SVN
> >> > version the
> >> > > file was last ported from.  Any other ideas on that?
> >> > >
> >> > > Michael
> >> > >
> >> > > Ciaran Roarty wrote:
> >> > >> George
> >> > >>
> >> > >> Thanks for the clarification. I think that you miss a central
> >> > >> point of what
> >> > >> I am trying to achieve and hopefully I will make this evident
> >> in my
> >> > >> response.
> >> > >>
> >> > >> I understand that changing Lucene.Net - I hesitate to keep using
> >> > >> the word
> >> > >> 'pure' - into a .NET 2.0 specific library is a big change.
> >> > >> However, I cannot
> >> > >> understand why you think changes in the internals of a class
> >> will
> >> > >> ripple all
> >> > >> the way up a chain. Obviously, if the accessible interface
> >> > changes
> >> > >> then we
> >> > >> would break calling code but much of the 'guts' of the code
> >> is not
> >> > >> accessible outside of the class.
> >> > >>
> >> > >> I understand your reticence to diverge effort but I regard this
> >> > >> exercise as
> >> > >> a complementary task - it depends on a stable release of
> >> > >> Lucene.Net; it does
> >> > >> not replace it. By attempting to create a .NET 2.0 library, the
> >> > >> community
> >> > >> can learn the lessons of how to take Lucene.Net to
> >> > Lucene.Net.2.0.
> >> > >> As you
> >> > >> rightly point out, there will be difficulties in doing this per
> >> > >> Lucene
> >> > >> release but if we learn how to do it now then we can drive
> >> > out those
> >> > >> difficulties and understand where they occur.... if we do not
do
> >> > >> it now then
> >> > >> we will not know and, I suggest, we will not be able to do it
in
> >> > >> the future
> >> > >> without far more pain.
> >> > >>
> >> > >> Does anyone on the list have an opinion on this? If the
> >> community
> >> > >> does not
> >> > >> think that there is any value in having a 'purer' Lucene.Net.2.0
> >> > >> then that's
> >> > >> fine; if this effort is not supported then I will let it go.
> >> > >>
> >> > >> Can you advise me of what is included in Lucene.Net 2.1 which
is
> >> > >> new? Is
> >> > >> there a published roadmap for Lucene?
> >> > >>
> >> > >> Ciaran
> >> > >>
> >> > >> On 03/04/07, George Aroush <george@aroush.net> wrote:
> >> > >>>
> >> > >>> Hi Ciaran,
> >> > >>>
> >> > >>> Your goal is well understood; my pushback with it is in the
> >> > >>> approach you
> >> > >>> are
> >> > >>> proposing and the timing.
> >> > >>>
> >> > >>> The current port is not 'purur' in the sense that it doesn't
> >> take
> >> > >>> advantage
> >> > >>> of what .NET 2.0 framework has to offer (this is because JLCA
> >> > >>> only targets
> >> > >>> .NET 1.1.)  Spinning off Lucene.Net 2.1 into another branch
and
> >> > >>> making it
> >> > >>> 'purur' will make life very difficult to keep up with any
> >> > >>> upcoming Java
> >> > >>> Lucene releases because the code base will be so different
> >> (in the
> >> > >>> Lucene.Net code base) to figure out what has changed in
> >> > >>> comparison with
> >> > >>> the
> >> > >>> Java version when porting 2.2 for example.  Not to mention,
it
> >> > >>> will also
> >> > >>> consume a good deal of our limited resources and to make the
> >> > >>> current code
> >> > >>> 'purur' is no easy task.
> >> > >>>
> >> > >>> If you are not convince, please give it a try.  You will see
> >> one
> >> > >>> change,
> >> > >>> in
> >> > >>> one file, leading to several changes across several files
(and
> >> > >>> keep in
> >> > >>> mind
> >> > >>> you also have all the "contrib" code too which must continue
to
> >> > >>> work.)
> >> > >>>
> >> > >>> Before we undertake this task, which I consider a very
> >> > >>> challenging task,
> >> > >>> I'm
> >> > >>> suggesting that we first prove yourself.  The prove will be
> >> that
> >> > >>> we get
> >> > >>> Lucene.Net 2.1 in a timely fashion, and that we can get the
C#
> >> > >>> Lucene's
> >> > >>> SVN
> >> > >>> in par with the Java Lucene's SVN.  If and when we achieve
this
> >> > >>> milestone,
> >> > >>> then we can start porting changes from the Java land to the
C#
> >> > >>> land on a
> >> > >>> weekly basic, or even sooner, and have the time to make
> >> > the existing
> >> > >>> Lucene.Net code base 'purur'.
> >> > >>>
> >> > >>> In a nutshell, there are more important and urgent work we
need
> >> > >>> to get
> >> > >>> done
> >> > >>> then start work on making the code 'purur'.
> >> > >>>
> >> > >>> Regards,
> >> > >>>
> >> > >>> -- George
> >> > >>>
> >> > >>> > -----Original Message-----
> >> > >>> > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
> >> > >>> > Sent: Tuesday, April 03, 2007 5:58 AM
> >> > >>> > To: lucene-net-dev@incubator.apache.org
> >> > >>> > Subject: Re: Lucene.NET Pure [was 'Lucene.Net project
> >> > >>> involvement']
> >> > >>> >
> >> > >>> > George
> >> > >>> >
> >> > >>> > Thanks for your comments. I don't want to reply to all
of
> >> > >>> > them and make the email completely unreadable so I will
try
> >> > >>> > to sum up my thoughts and see where we go from there.
> >> > >>> >
> >> > >>> > I think we have conflicting views of what a 'pure' Lucene.Net
> >> > >>> > is and I'd like to make my case more clearly as I cannot
> >> > >>> > imagine that you would have a problem with it.
> >> > >>> >
> >> > >>> > Lucene.Net will always be driven by Lucene as the community
> >> > >>> > around Lucene is mature and developing at pace compared
to
> >> > >>> > Lucene.Net; this is not a criticism, it is a fact of
life.
> >> > >>> > What I don't understand is how that development is
> >> > >>> > progressing - i.e. what features are being added, what
> >> > >>> > features are being removed, if performance is being
> >> > >>> > improved...... I presume you have a far better understanding
> >> > >>> > of those realities.
> >> > >>> >
> >> > >>> > Now, Lucene.Net is a fully functioning, very performant,
> >> > >>> > extremely useful component / library / product. I cannot
> >> > >>> > emphasise how important Lucene.Netwas in developing a
viable
> >> > >>> > search strategy for a project I was working on recently.
> >> > >>> > However, I wanted the library to be a .NET 2.0 library;
not
> >> > >>> > just compiled under .NET 2.0.... I have an aversion to
> >> > >>> > ArrayLists, for example, and I'd like them to be replaced
by
> >> > >>> > Generic Collections.
> >> > >>> >
> >> > >>> > So, to achieve these two aims: keeping up with Lucene
and
> >> > >>> > making Lucene.Netmore .NET 2.0 specific, I think we have
to
> >> > >>> > prove the process..... By that, I mean we need to take
a
> >> > >>> > Lucene.Net release - I suggest 2.1 - and branch the codebase.
> >> > >>> > What this allows us to do, is to revise the Lucene.Net
> >> > >>> > release without affecting Lucene.Net's ability to move
> >> > >>> > forward with Lucene enhancements and improvements whilst
- in
> >> > >>> > a low risk environment - learn the lessons of making
> >> > >>> > Lucene.Net 'purer.'
> >> > >>> >
> >> > >>> > Does that make sense?
> >> > >>> >
> >> > >>> > Basically, I am happy with the functionality in Lucene.Net
> >> > >>> > just now and I think it would be a good thing to have
an
> >> > >>> > optimised, purer .NET 2.0 version of the library. I
> >> > >>> > understand that the Lucene.Net / Lucene relationship
should
> >> > >>> > not be broken as Lucene is clearly still developing and
we,
> >> > >>> > as a community, can gain from this continued development.
> >> > >>> > However, I think the community can also gain from the
> >> > >>> > development of an optimised for .NET 2.0version of the
> >> library.
> >> > >>> >
> >> > >>> > That's my thinking. It is what I am truly interested
in
> >> > >>> > doing. I think the community would respond well to a
version
> >> > >>> > of Lucene.Net which is optimised for .NET 2.0 and I think
we
> >> > >>> > will struggle to do that with Lucene.Net alone as it
> >> > >>> > necessarily follows Lucene developments.
> >> > >>> >
> >> > >>> > Thanks for reading,
> >> > >>> > Ciaran
> >> > >>> >
> >> > >>> > On 03/04/07, George Aroush <george@aroush.net>
wrote:
> >> > >>> > >
> >> > >>> > > Hi Ciaran,
> >> > >>> > >
> >> > >>> > > Please see my comments below.  Thanks.
> >> > >>> > >
> >> > >>> > > -- George Aroush
> >> > >>> > >
> >> > >>> > > > -----Original Message-----
> >> > >>> > > > From: Ciaran Roarty [mailto:ciaran.roarty@gmail.com]
> >> > >>> > > > Sent: Monday, April 02, 2007 6:44 AM
> >> > >>> > > > To: lucene-net-dev@incubator.apache.org
> >> > >>> > > > Subject: Lucene.NET Pure [was 'Lucene.Net project
> >> > >>> involvement']
> >> > >>> > > >
> >> > >>> > > > Hi
> >> > >>> > > >
> >> > >>> > > > I just want to check some facts and see if
I have
> >> > picked up
> >> > >>> the
> >> > >>> > > > right emphasis from the majority of the posts.
> >> > >>> > > >
> >> > >>> > > > Firstly, Lucene.NET 2.1 is due to be released
soon.
> >> > >>> > >
> >> > >>> > > Yes, Lucene.Net 2.1, a first cut release should
be out by
> >> > >>> > end of this
> >> > >>> > > week or over the coming weekend.  Btw, it's "Lucene.Net"
> >> > >>> > and not "Lucene.NET"
> >> > >>> > >
> >> > >>> > > > Secondly, the port of Lucene to Lucene.NET
is not
> >> > an automatic
> >> > >>> > > > process and George does post-migration work
currently to
> >> > >>> > bring the
> >> > >>> > > > JLCA work closer to the .NET world.
> >> > >>> > > >
> >> > >>> > > > Using the Lucene.NET effort, people on this
list have
> >> > >>> > gone away and
> >> > >>> > > > made the port of Lucene into a purer .NET version.
> >> > >>> > > > These changes have, however, stayed internal
to their
> >> > >>> > work and they
> >> > >>> > > > have not been backported.
> >> > >>> > >
> >> > >>> > > Are you sure about this?  I have not read anyone
saying
> >> > >>> this.  What
> >> > >>> > > folks have said is that they eliminated unnecessary
> >> > >>> exceptions from
> >> > >>> > > the Lucene.Net code; exceptions that also exist
in the Java
> >> > >>> version
> >> > >>> > > and were brought over to C# via the port.  There
is a JIRA
> >> > >>> > issue about
> >> > >>> > > this and we had a long discussion about it on this
mailing
> >> > >>> > list some
> >> > >>> > > time ago.  The folks on the Java mailing list knew
about it
> >> > >>> > and fixed
> >> > >>> > > it for 2.1 release.
> >> > >>> > >
> >> > >>> > > > When I asked the question about getting involved
in the
> >> > >>> > project and
> >> > >>> > > > making Lucene.NET 'purer' - in a .NET sense
- then there
> >> > >>> > appeared to
> >> > >>> > > > be a real desire to get involved with that
process. It
> >> was
> >> > >>> also
> >> > >>> > > > noted that this would need to be a manual process;
I
> >> > >>> > suggested that
> >> > >>> > > > the next major release - Lucene.NET 2.1 - should
be the
> >> > >>> basis for
> >> > >>> > > > this work.
> >> > >>> > > >
> >> > >>> > > > Therefore, I think we should branch the code
at 2.1 and
> >> > >>> > work on that
> >> > >>> > > > branch.
> >> > >>> > > > In that way, we do not stop the progress of
Lucene.NET in
> >> > >>> > line with
> >> > >>> > > > Lucene but we do get to make some .NET optimisations.
> >> > >>> > >
> >> > >>> > > I disagree about branching off a new baseline. 
Like
> >> > I said in a
> >> > >>> > > previous posting, the first thing we need to do
is bring up
> >> > >>> > Lucene.Net
> >> > >>> > > to be in part with the code base of what's in the
Java
> >> > >>> > Lucene SVN with
> >> > >>> > > what's in the C# Lucene SVN.  Once we achieve this
> >> > important but
> >> > >>> > > difficult milestone, and most importantly we prove
that
> >> we can
> >> > >>> > > maintain it, then we can start looking at the existing
code
> >> > >>> > base and
> >> > >>> > > make the code .NET 'purer'.
> >> > >>> > >
> >> > >>> > > > Lastly, I believe that .NET 2.0 was the preferred
> >> > >>> > platform for this
> >> > >>> > > > work and that it would be ok to use .NET 2.0
specific
> >> > >>> > capabilities.
> >> > >>> > >
> >> > >>> > > Yes, the work on Lucene.Net 2.1 will be release
.NET 2.0
> >> > >>> > specific; but
> >> > >>> > > again, our first goal must be that we get in par
with
> >> Java's
> >> > >>> Lucene
> >> > >>> > > SVN before we diverge the code into more .NET.
> >> > >>> > >
> >> > >>> > > > Does that sound right? Any builds on this?
Any problems
> >> > >>> with the
> >> > >>> > > > approach?
> >> > >>> > > >
> >> > >>> > > > Thanks in advance,
> >> > >>> > > > Ciaran Roarty
> >> > >>> > > >
> >> > >>> > >
> >> > >>> > >
> >> > >>> >
> >> > >>>
> >> > >>>
> >> > >>
> >> >
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message