I'm fine with using jpackage as the "official" or recommended binary distribution for RPM-based distributions. This solves part of the problem.
To make sure everyone understand, this will mean we support the following layout for FHS-based linux systems, in addition to our
typical layout:
- config files in /etc/tomcat5/
- logs in /var/log/tomcat5
- workdir and tempdir in /var/cache/tomcat5/[temp/work]
- webapps will be deployed on /var/lib/tomcat5/webapps
- lib dirs under /var/lib/tomcat5/[commons/shared/server]
- homedir and bin under {datadir}/tomcat5 ( not sure what datadir is, Henri ? )
- only tomcat files included, all other .jars will come from separate
- dependent RPMs you need to install: .... ( there seem to be 10+ )
I am still unable to get jpackage installed via apt on fedora2 ( 6 dependent "not installable" ) - if I get it working I'll post the exact paths and dependencies.
This will be in addition to the normal layout most documentations and books typically assume:
- webapps in $CATALINA_HOME/webapps
- config in $CATALINA_HOME/conf
- longs in ../logs
- a script called "catalina.sh" that takes the CATALINA_HOME env and does a number of actions in certain way
- ...
Should I make a proposal to make those 2 layouts "official" ? Is it ok if we recommend the second layout to be used whenever possible - i.e. in non-FHS-limited distributions ? Do we want to also define a default base dir - like /usr/local/tomcat5 or /opt/tomcat5 ( similar for 4 ) ?
I can write a .spec file to create a RPM in the second layout - and I'm pretty sure I can integrate the building of the RPMs in the build.xml ( cygwin can be used on windows to generate RPMs AFAIK - I need to try )
My preference will be to at least include the second "full tomcat/easy to install/same layout as on other OSes" non-FHS RPM in the release, even if you don't agree to make it the default/recommended one.
The main benefit is that people can then easily write scripts and install files ( RPM, etc ) to easily deploy webapps or extensions, and support will be much easier. At least they would have to maintain only 2 versions of their packages instead of one for each linux distro.
The second big question is what do we do to promote this layout and prevent fragmentation. Options:
- include some text in the release notes or on the web page
- add a piece of code that checks at runtime and display a strong warning that people shouldn't use that package ( or shouldn't contact tomcat for problems ). If someone removes this - it will become a derivative work, so maybe we can use something in license.
- place "don't use" links to RPMs/distros using non-standard layouts ?
- add some Sun-like rules - pass the unit tests and basic load tests,
don't remove things, use one of the recommended layouts - in order to list the distro as "compatible" ?
Finally - am I overreacting, are other people seeing this as a real issue, or should we just ignore the problem like apache does ?
I would answer no, as the stability issue is a big problem (the HTTPd doesn't have that issue; why is the worst left to us ? :/). The directory layout is a less critical issue.
(we can't do the last point: the license allows basically anything)
R�my
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
