Hi Hoss, Thanks for your comments. I'm cc-ing three of the Debian Java package maintainers that also work on Lucene packaging.
Chris Hostetter wrote:
> : as a Tomcat 5.5 webapp. I got the package working, but I would like the
> : package to use the Debian-supplied lucene and xpp3 .jar files, which
> : with Debian are installed under /usr/share/java. It is Debian policy not
> : to unnecessarily duplicate .jars on the same system.
> :
> : I've tried the following approaches without success:
>
> 1) can you define "without success"? what was the observed behavior?
>
Sorry, I should have been more explicit.
- without the .jars in WEB-INF/lib:
Jun 4, 2007 10:09:24 AM org.apache.catalina.core.StandardContext
loadOnStartup SEVERE: Servlet /solr threw load() exception
java.lang.NoClassDefFoundError: org/apache/lucene/search/Searcher
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at
org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1815)
at
org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:869)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1322)
at
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1201)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
at org.apache.solr.servlet.SolrServlet.init(SolrServlet.java:72)
(....)
- with symlinks from the .jars in /usr/share/java to WEB-INF/lib:
exactly the same error
- with symlinks from the .jars in /usr/share/java to
/usr/share/tomcat5.5/shared/lib:
exactly the same error
- by including the full path to the lucene jar in
<webapp>/META-INF/MANIFEST.MF
exactly the same error
- by including the full path to the lucene jar in META-INF/MANIFEST.MF
in <webapp>/WEB-INF/lib/solr-XXXX.jar
exactly the same error
> 2) i'm vaguely familiar with debian policy on "no redundency" but i'm not
> sure it relaly applies here ... the published releases of Solr only
> include one jar: the solr.jar (which contains solr source code for use in
> compiling plugins). other jars are bundled into the solr.war which should
> be considered a single "binary" entity ... much like a C app might link in
> a bunch of independently compiled object files. attempting to
> "extract" those jars from the solr.war and reuse other jars installed by
> other packages is like trying to unlink that C program and make it use
> shared object files instead --- it's a pretty big leap.
>
It's not too bad (at least for solr-1.1.0, haven't looked at the
upcoming 1.2.0 yet). To create the .deb, the java sources in the solr
source distribution tarball are compiled. I remove the .jars under lib/
before compiling and add the needed .jars from /usr/share/java to
compile.classpath in build.xml instead. The sources are compiled using
ant dist-war. The resulting .war-file is unpacked into the package file,
which upon package installation will put them in /usr/share/solr/.
Tomcat configuration points the /solr/ context to /usr/share/solr/. That
goes all very well, except that I cannot get Tomcat, when the package is
installed, to load the Lucene classes from the .jars in /usr/share/java,
hence my question.
> 3) Some of the jars Solr inlcudes in it's war are not the officially
> released version of third party software. We frequently use development
> versions (varefully noting which version in our README) when we feel they
> are stable enough and provide important features. For this reason, you
> may find it hard to achieve your goal in a forward maintainable manner no
> matter what.
>
That may be a problem. For the depencies on Lucene, it may mean I should
either wait for the next Lucene release before packaging the previous
Solr release, or package a development Lucene release separately (I'm
also one of the maintainers of the Debian Lucene package).
The other libraries of which Solr uses unreleased versions (by the way,
that are not noted in the README in the subversion repository, but I'm
guessing from the jarfile names in lib/) are
commons-csv-0.1-SNAPSHOT.jar and maybe easymock.jar.
Common-csv is not releases, but I don't think it would be a fast-moving
target, so I could package it for Debian before the official release.
Is easymock.jar also a development version?
Thanks for your time!
Cheers
Jan-Pascal
signature.asc
Description: OpenPGP digital signature
