On Thu, 15 Apr 2010, Robert Muir wrote:
2010/4/15 Michael McCandless <luc...@mikemccandless.com>
I realize the migration tool has issues -- it fixes the hard
changes
but silently allows the soft changes to break (ie, your
analyzers my
not produce the same tokens, until we move all core analyzers
outside
of core, so they are separately versioned), but it seems like a
good
compromise here?
Well, lets consider doing that too. Since analyzers have this tough problem
of being "soft changes", I propose the following:
1. get rid of version
2. minimize the interface between the indexer and analysis
3. put analyzers in their own versioned jar files.
Yes, every analyzer needs to have its own version and thus, jar file.
Putting all analyzers into one versioned jar file joins them at the hip and
suffers from the same versioning and compat problems we're currently facing
in core.
Andi..
this way, we could provide a realistic capability for users to use
lucene-3.5.jar with lucene-3.2-analyzers.jar, and possibly have STRONGER
analyzer back compat (e.g. if we minimize the damn thing enough, perhaps
very old analyzers.jar's could even work across major releases).
its also much safer when you are using the same bytecodes you used before,
instead of hairy back compat layers. I don't refer to Uwe's code here: its
perfect, but we cant force Uwe into writing the back compat for every big
feature.
--
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
