On Sun, Feb 7, 2010 at 8:38 PM, Robert Muir <rcm...@gmail.com> wrote: > Simon, can you explain how removing CURRENT makes it harder for users to > upgrade? If you mean for the case of people that always re-index all > documents when upgrading lucene jar, then this makes sense to me. That is what I was alluding to! Not much of a deal though most IDEs let you upgrade via refactoring easily and we can document this too. Yet we won't have a drop in upgrade anymore though.
> > I guess as a step we can at least deprecate this thing and strongly > discourage its use, please see the patch at LUCENE-2080. > > Not to pick on Sanne, but his wording about: "Of course more advanced use > cases would need to pass parameters but please make the advanced usage > optional", this really caused me to rethink CURRENT, because CURRENT itself > should be the advanced use case!!! > > On Sun, Feb 7, 2010 at 2:34 PM, Simon Willnauer > <simon.willna...@googlemail.com> wrote: >> >> Sanne, I would recommend you building a Factory pattern around you >> Analyzers / TokenStreams similar to what solr does. That way you can >> load you own "default ctor" interface via reflection and obtain you >> analyzers from those factories. That makes more sense anyway as you >> only load the factory via reflection an not the analyzers. >> >> @Robert: I don't know if removing LUCENE_CURRENT is the way to go. On >> the one hand it would make our live easier over time but would make it >> harder for our users to upgrade. I would totally agree that for >> upgrade safety it would be much better to enforce an explicit version >> number so upgrading can be done step by step. Yet, if we deprecate >> LUCENE_CURRENT people will use it for at least the next 3 to 5 years >> (until 4.0) anyway :) >> >> simon >> >> On Sun, Feb 7, 2010 at 8:17 PM, Sanne Grinovero >> <sanne.grinov...@gmail.com> wrote: >> > Thanks for all the quick answers; >> > >> > finding the ctor having only a Version parameter is fine for me, I had >> > noticed this "frequent pattern" but didn't understand that was a >> > general rule. >> > So can I assume this is an implicit contract for all Analyzers, to >> > have either an empty ctor or a single-parameter of type Version? >> > >> > I know about the dangers of using LUCENE_CURRENT, but rebuilding the >> > index is not always something you need to avoid. >> > Having LUCENE_CURRENT is for example useful for me to test Hibernate >> > Search towards the current Lucene on classpath, without having to >> > rebuild the code. >> > >> > thanks for all help, >> > Sanne >> > >> > >> > 2010/2/7 Robert Muir <rcm...@gmail.com>: >> >> I propose we remove LUCENE_CURRENT completely, as soon as TEST_VERSION >> >> is >> >> done. >> >> >> >> On Sun, Feb 7, 2010 at 12:53 PM, Uwe Schindler <u...@thetaphi.de> wrote: >> >>> >> >>> Hi Sanne, >> >>> >> >>> Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is >> >>> the >> >>> badest thing you can do if you want to later update your Lucene >> >>> version and >> >>> do not want to reindex all your indexes (see javadocs). >> >>> >> >>> It is easy to modify your application to create analyzers even from >> >>> config >> >>> files using the reflection way. Just find a constructor taking Version >> >>> and >> >>> call newInstance() on it, not directly on the Class. It's just one >> >>> line of >> >>> code more. >> >>> >> >>> Uwe >> >>> >> >>> ----- >> >>> Uwe Schindler >> >>> H.-H.-Meier-Allee 63, D-28213 Bremen >> >>> http://www.thetaphi.de >> >>> eMail: u...@thetaphi.de >> >>> >> >>> > -----Original Message----- >> >>> > From: Sanne Grinovero [mailto:sanne.grinov...@gmail.com] >> >>> > Sent: Sunday, February 07, 2010 6:33 PM >> >>> > To: java-dev@lucene.apache.org >> >>> > Subject: Having a default constructor in Analyzers >> >>> > >> >>> > Hello, >> >>> > I've seen that some core Analyzers are now missing a default >> >>> > constructor; this is preventing many applications to configure/load >> >>> > Analyzers by reflection, which is a common use case to have >> >>> > Analyzers >> >>> > chosen in configuration files. >> >>> > >> >>> > Would it be possible to add, for example, a constructor like >> >>> > >> >>> > public StandardAnalyzer() { >> >>> > this(Version.LUCENE_CURRENT); >> >>> > } >> >>> > >> >>> > ? >> >>> > >> >>> > Of course more advanced use cases would need to pass parameters but >> >>> > please make the advanced usage optional; I have now seen more than a >> >>> > single project break because of this (and revert to older Lucene). >> >>> > >> >>> > Regards, >> >>> > Sanne >> >>> > >> >>> > >> >>> > --------------------------------------------------------------------- >> >>> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> >>> > For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >>> >> >>> >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> >>> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> >>> >> >> >> >> >> >> >> >> -- >> >> Robert Muir >> >> rcm...@gmail.com >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: java-dev-h...@lucene.apache.org >> > > > > -- > Robert Muir > rcm...@gmail.com > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
