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 ?
Costin
Shapira, Yoav wrote:
Hi, Note also the Apache license 2.0 (not 1.1) is what applies.
I sent this earlier (this weekend) but it didn't get through: why duplicate the efforts of the good folks at JPackage.org? They typically have RPMs for tomcat releases a day or two after we cut the release. They have been friendly, responsive, and most importantly their RPMs are good on numerous platforms that people on the mailing list have tried. Instead of creating our own RPMs, why not point (in docs, or a link somewhere) to the JPackage.org ones? http://www.jpackage.org/
Yoav Shapira Millennium Research Informatics
-----Original Message----- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Monday, May 17, 2004 1:59 AM To: Tomcat Developers List Subject: RE: Fedora "tomcat"
-----Original Message----- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: May 16, 2004 10:04 PM To: [EMAIL PROTECTED] Subject: Re: Fedora "tomcat"
It's not a "derivative" - it's the same tomcat code, just placed in weird directories and using a different VM ( which is a bit "experimental"), and it seems less stable because of how it is compiled.
Fair enough - you're in a better position to judge that than I am.
...
IMO it's not a problem with fedora - but with tomcat ( and with many other open source projects ). We can at least provide a standard layout and some basic requirements ( like passing the unit tests and some load tests ), and have some official RPM distribution for rpm-based linux. We do it for windows - why not for linux ?
That sounds good.
Steve
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
