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.