Patch with MorfologikFilterFactory and test added.

Hi Rafał. Could you modify this patch to include support for the three dictionaries (combined, morfeusz and morfologik)? This would be more flexible (and the combined dictionary is nearly twice larger than morfologik itself so it's worth it).

return new MorfologikFilter(ts, DICTIONARY.MORFOLOGIK, luceneMatchVersion);

Also, an example of use in the JavaDoc would be nice (see BeiderMorseFilterFactory for example). The test should be using DEFAULT_VERSION not the fixed LUCENE_40. Thanks!

Sure Dawid, no problem. I'll provide a patch later today.

Thanks. Sorry about the name confusion btw. Don't know where I took Michał from

Dawid, I've uploaded new patch. One thing I noted is that the ant build throws an error because it can't find Morfologik libraries.

I'll patch the build files tomorrow.

Thanks Rafał.

Dawid, I've looked at the build files and how libs are handled. My proposition is to copy the jar's from the modules/morfologik/lib to solr/contrib/analysis-extras/lib similar to the way the ICU lib is handled. What do you think about that ?

I've also updated the patch, to have javadocs example usage.

I actually don't know what the policy is – I asked on the dev list, we'll see what solr folks prefer.

Hi, the patch has one problem (unrelated to the JAR file problem): It uses toUpperCase() without locale, so uppercasing with e.g. Turkish locale will fail horrible. This type of code must use toUpperCase(Locale.ENGLISH).

It the JAR file already included with analysis module? I don't really understand the problem with the JAR file.

Ah I see, the dictionaries are already there. In that case we would not duplicate them inside the Solr tree. It should stay in analysis module. We can move them during build and war-file creation to solr, like we do with other lucene jars.

I'll update the patch and the build files, thanks for comments.

Thanks Uwe. Btw. should we apply it to 3.x as well? This seems like a harmless patch and it'd be a nice-to-have feature.

There is no morfologik in 3.x. I asked about that before but you seemed a tad offended
at the prospect of a java5 version

Damn. [Blushing].

I could prepare a 1.5 compatible version with retroweaver and integrate it in. I guess now I don't have excuses, do I... Do we want to push it in at the last minute though?

I have no objection, as long as all new files:

• have package.html
• have some javadocs for each class
• have apache license header

and assuming its in by tomorrow (when i will freeze).

Stuff like new analyzers that weren't available before aren't really risky,
because they won't break any existing functionality.

Corrected toUpper to use Locale.ENGLISH

I attach a patch that introduces subtle changes (enum.valueOf never returns null, it throws an exception on invalid values).

There is also my take at build integration although I have no idea if I did it right – where is the code that copies these JARs to solr? The code compiles for me but the war file doesn't have any contribs, for example (they're optional?).

Can I ask somebody to look at the build file changes (and determine if morfologik JARs should be copied and where). Otherwise this is ready to be committed I think.

After some deliberation I won't rush to make Morfologik part of 3.x – last minute features are the worst.

where is the code that copies these JARs to solr?

The dist target in solr/webapp/build.xml depends on lucene-jars-to-solr in solr/common-build.xml, which makes sure that lucene .jar dependencies are built (via prep-lucene-jars), and then copies them to solr/build/lucene-libs/, the contents of which are then packaged into the .war. Dawid, I think this is where you want to make changes.

More packaging details:

The dist target in solr/webapp/build.xml also runs the contribs-add-to-war target from solr/common-build.xml, which invokes add-to-war in each Solr contrib that has a src/webapp/ directory (currently only DIH) to copy the contents of src/webapp/ to solr/build/web/, the contents of which are then packaged into the .war.

Lastly, the create-package target in solr/build.xml depends on the dist target, which depends on the dist-contrib target, which invokes dist in each Solr contrib. Solr contribs that want to include lucene .jar dependencies in the Solr distribution (but not the .war) have their dist targets populate solr/build/contrib/<contrib-name>/lucene-libs/ with those .jars. The create-package target then invokes add-lucene-libs-to-package in each Solr contrib, which copies the contents of solr/build/contrib/<contrib-name>/lucene-libs/ to solr/build/contrib-lucene-libs-to-package/contrib/<contrib-name>/. Finally, the distributions (tarball/zip) include the contents of solr/build/contrib-lucene-libs-to-package/.

Wow, that last part is way more complex than it needs to be. (And it's totally my fault )

Before Robert and I rewrote the Solr build, the top-level Solr build file was huge. One of the guiding principles I used was "keep build configuration local". Now individual modules handle the details that only concern them. Coordination among modules, as seen in the above packaging description, remains a challenge...

Final patch (applied).

Applied the patch. Thanks for clarifications concerning build deps, Steven. I've built and dist and the JARs make it under WEB-INF/lib so all seems good.

This is in trunk now, thanks Rafał.