[
https://issues.apache.org/jira/browse/LUCENE-5858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079624#comment-14079624
]
Hoss Man commented on LUCENE-5858:
----------------------------------
bq. Its not mandatory today. Its only mandatory for tests, which is the
advantage, there is no risk to the build system moving stuff there. It removes
it from the core jar and makes it optional, whereas today its mandatory.
I guess i'm misunderstanding something about your initial suggestion. (There
are also a lot of instances of "It" in that paragraph that that are confusing
me about which "it" you are refering to at any given time ... sometimes it
seems like "it" is the codecs module, other times i think "it" refers to the
backcompat codecs?
Here's the point i was trying to make...
Today: a simple-app.jar that wants extremely basic search functionality, can
depend exclusively on lucene-core.jar and build an index and search that index.
If that simple-app.jar built an index with lucene-core-4.5.jar and then later
upgraded to use lucene-core-4.9.jar, then simple-app.jar would continue to work
just fine
If i understand your idea correctly: then starting in 4.10 the back compat
codecs would now live in lucene-codecs.jar. So simple-app.jar would need to
include both lucene-core-4.10.jar and lucene-codecs-4.10.jar in it's classpath
if it wanted to keep reading those older 4.5-4.9 indexes. There might however
be some trivial-app.jar that doesn't care about index backcompat at all, and it
only needs to load lucene-core-4.10.jar
Am i correct so far?
The concern i have is that when it comes to upgrading, the "simple-app.jar"
scenerio seems more common to me then the "trivial-app.jar" situation, and for
the simple-app.jar situation, moving the backcompat codecs into
lucene-codecs.jar doesn't actually do anything to reduce the "bloat" of classes
in the lucene jars it includes -- it makes the bloat worse -- because now in
addition to the core classes, and the backcompat codecs, simple-app.jar also
has to include all of the "optional" codecs (like simpletext) that already
exist in the lucene-codecs.jar.
The bloat of unnecessary classes has been reduced for trivial-app.jar, but is
that really the situation we should be optimizing for?
The key question i'm raising is:
Does it really make sense to _increase_ the size of jars needed for apps that
want to read old indexes, in order to _decrease_ the size of the jars needed
for (in my opinion) "toy" apps that don't care about index compatibility?
Moving the backcompat codecs into their own jar seems like a great idea -- i'm
just not sure if any "real" lucene users benefit from moving them into the
_existing_ codecs jar.
> Move back compat codecs out of core/ into codecs/ jar
> -----------------------------------------------------
>
> Key: LUCENE-5858
> URL: https://issues.apache.org/jira/browse/LUCENE-5858
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
>
> These take significant space and bloat core lucene. Not everyone needs the
> ability to read ancient indexes (especially building a new app).
> We should move this cruft out of the core/ jar. codecs/ is the obvious place,
> its already setup in the build system for tests and everything else.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
