Sorry... lemme try to explain in more detail:
can you be specific as to what you mean by "the morfologik jars" ? because evidently i don't have a clue what that means and i missunderstood what you were including in that list originally (i thought you ment all of the anlysis-extra libs that weren't ICU).
WEB-INF/lib/lucene-analyzers-morfologik-4.0-SNAPSHOT.jar <-- this is the lucene integration code (analyzer, tokenfilter)
WEB-INF/lib/morfologik-fsa-1.5.3.jar <-- these 3 jars are dependencies of the above
But this does not good for solr users: because the factory (MorfologikFilterFactory.java) is in apache-solr-analysis-extras.jar. Furthermore, I think having this situation (where these files are in the war, but the factory as a plugin) causes classloader hell.
So with the factory in this contrib module, the jar files should really be going in contrib/analysis-extras/lucene-libs as part of the packaging process just like the other dependencies this contrib module has, otherwise we should move the factory to core (see below)
are you saying it is good or bad that lucene-analyzers-smartcn is not currently in solr core? (ie: in your opinion, should SmartChinese*Factory move into solr/core ?)
In my opinion, it would be nice because we could have a text_zh configured in the example that indexes chinese as words. Currently to do this, you have to deal with this huge hassle that is this crazy analysis-extras contrib which is a big barrier for indexing Chinese text.
But thats just my opinion, i hate the contrib in general because I think its a pain to use. The reason it exists was because I initially wanted to integrate smartchinese with solr but there were concerns about it increasing the size of the .war file since the smart chinese jar is 3MB. So I created this contrib and added factories for any analyzers that didnt have factories just as a way of at least providing some help to make them usable. Just FYI: the solr.war is near 20MB now.
Still, as it is, at least its some way to provide factories for these analyzers versus having none before.
again: what exactly do you mean by "wrong place" ?
am i correct in understanding that you feel they should be in the war file, but that it is a mistake they are not included in solr.base.classpath at compile time?
Under the current setup, the factory is in contrib/analysis-extras. the contrib/analysis-extras build logic puts these dependencies into contrib/analysis-extras' classpath so the tests will pass.
If we want to move the factories to core, then we have to adjust the solr core classpath to then include the jar files instead.
a quick glance at that reveals other things in that classpath that shouldnt be in there like analyzers-uima.jar (which, should instead be configured in the uima contrib's classpath only)
Here is contrib/uima/build.xml:
So its useless to have analyzers-uima in the solr core classpath, because in the current packaging solr core code should not be depending on this jar. And contrib/uima already adds this itself.