ok, I think you have a valid case for using this for testing. We just have to be careful about wording and such, because i think right now we encourage users to use this constant. I created a patch to make it scary and deprecated under LUCENE-2080, we don't have to remove the constant just keep it forever deprecated as it breaks backwards compatibility to use it.
as far as implicit contract of no-arg/Version ctor for analyzers i do not think this is the case. someone can make an analyzer with a required argument if they want to, and I think some analyzers have this already (PerFieldAnalyzerWrapper at least) On Sun, Feb 7, 2010 at 2: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 > > -- Robert Muir rcm...@gmail.com
