Excerpts from Nicolas Mailhot's message of Thu Mar 10 09:55:47 +0100 2011:
>
> Le Mer 9 mars 2011 15:44, Stanislav Ochotnicky a Ãcrit :
> > I've been asked to package apache-solr [1] in Fedora. This is a java
> > library and webapp posing as a frontend to lucene for searching.
> >
> > Packaging java jars is not a problem, but there are more problems with
> > webapp part. I made it into subpackage apache-solr-webapp. Ant build
> > creates war file (basically a zip with metadata and dependencies
> > bundled). I expand this war file and replace dependencies with
> > symlinks to %{_javadir}. I then place content of this directory inside
> > /usr/share/java/webapps/apache-solr/. This makes it possible to use
> > webapp in container (tomcat/jetty) while enabling us to update
> > dependencies independently.
>
> This is nothing new and actually why jpackage-utils contains a
> build-jar-directory command that populates a directory with symlinks (and a
> rebuild-jar-directory that refreshes them if necessary)
Yes. I of course know about build-jar-repository (typo on your
part?). Question wasn't so much about that, but general approach since
AFAIK there was no previous Java Webapp in Fedora (therefore noone
dealt directly with war files).
>
> /usr/share/java/webapps/ is likely to conflict with this command logic BTW.
> /usr/share/java/ was supposed to contain only jars on jpackaged systems
> originally.
This is I guess more problematic aspect I haven't really though of. I
don't really think it would cause practical issues, but I agree it's
better to get it right(tm). So how about /usr/share/java-webapps ? Or
to have nice ordering with php(?) webapps /usr/share/webapps-java.
> > I was thinking about adding default configuration for tomcat inside
> > yet another subpackage. But this would be just one simple xml file
> > inside /etc/tomcat6/Catalina/localhost/. Plus solr needs additional
> > configuration:
> > * creating of SOLR_HOME directory and placing it somewhere, presumably
> > /var/lib/solr). I have example solr home dir in %doc, but it is generic
> > and configuration is not really usable in that state for anything
> > other than serve as a commented example.
> >
> > All in all seems like too much of a hassle for little gain.
>
> It's not little gain. If you find it too complex to do manually, the usual
> solution is to write rpm macros or shell helpers to help deploy this kind of
> webapp.
I meant little as at least in this case it really requires manual
modifications of SOLR_HOME and I have a feeling people would try to
use default configuration. Even if you use upstream war file you still
have to do these things, because for example you have to change
property of solr.home for given tomcat instance/context or it just
won't work.
Problem with putting SOLR_HOME into var is that there are
configuration files that would fit more in the /etc. Then it's not so
intuitive to understand how to run two instances, because deploying it
twice will not work without having separate SOLR_HOME and configs. Oh
well..I guess I'll just concentrate on making one instance work
more-less out-of-the box and let them figure out how I did it...
It's really not a technical issue, more of a "what's the most normal
way" issue :-)
--
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
