Ok, not even sure where to start so I will kinda just jump in with this. I am not looking to start a flame war, or long thread. I would prefer this thread not to grow beyond this post. As there are better places, like Gentoo java mailing list, gentoo forums, irc, etc. In the Gentoo Tomcat Guide[1] I request users do this before say contacting upstream mailing lists or etc. Like what happened in this case.
I am the present maintainer of Tomcat on Gentoo. I started doing so a year ago when I noticed 5.0.27 was the lastest stable, and 5.5.x was pretty far from hitting the tree, despite being almost a year old at the time. The Tomcat maintainer was mia. So I slowly took over and eventually became an official dev. To being with, on Gentoo we compile Open Source Software from source. This is quite common in the FOSS world everywhere except for Java.[2] For some reason you can't get Apache http server binaries, but you can get Tomcat binaries. With that said, compiling Tomcat from source is COMPLETELY different than downloading a pre-built binary version of Tomcat. That has bundled dependencies. As in third party jars not part of Tomcat, but shipped with it. Because Tomcat needs them to run. Now keep in mind not only are we compiling Tomcat from source, we are compiling all of Tomcat's dependencies from source as well. Which leads to considerable dependencies. So package A depends only on B, but to build package B might need/depend on the entire alphabet :) Tomcat 5.5.20, has a ton of build time dependencies with even more optional dependencies. It's not clear if the optional dependencies activate functionality or not within Tomcat. Some of these in question are like Sun's jaf and javamail. Which till recent were not open source or easily available, and could only be obtained as binaries from Sun. So instead of having a potentially limited functionality Tomcat, we provide all possible dependencies, as would be present when Tomcat devs build and package Tomcat. Others can't be bi-passed at all. Try compiling Tomcat with say IBM JDK. You will notice classes are missing. Because only Sun JDK's and blackdown implement JSSE. There is talk of removing that SSL code, and pretty sure has been done with Tomcat 6.0.x. We don't even package JSSE on Gentoo, since it's a pre 1.4 tech. Tomcat is one of the only apps that is using or needs that stuff. Now Tomcat 6.0.x has WAY less deps. A MUCH cleaner and clearer build/compile process. Despite a bit of nastiness still going on. Like naming-factory-dbcp.jar called tomcat-dbcp.jar. Is basically a slightly modified re-packaged and compiled from source commons-dbcp, commons-pool, and commons-collections. Most all Tomcat packagers for Linux distros have voiced their opinion on how that jar is built. So far seem to have fallen on deaf ears. Finally let me apologize for that unfortunately user who decided to post here first. Rather than contacting the proper channels first. Seems there is lots they don't get about the distro they have chosen to run. Much less where to go with questions, problems, or for help with distro provided packages. 1. http://www.gentoo.org/proj/en/java/tomcat-guide.xml 2. http://www.gentoo.org/proj/en/java/why-build-from-source.xml P.S. For anyone that has a real problem with the dependencies. Our build system on Gentoo, specifically ebuilds, are just bash scripts. So one is totally free to modify and attempt to reduce the Tomcat's dependencies on Gentoo. Good luck there, don't think I haven't tried and haven't been there. As is seems to be an issue with our java5 USE flag. Either a dropped dep, or compiling Tomcat as 1.5 source/target is causing catalina.jar to be off a bit. Lacking some functionality or code as it seems. Dropping other deps would likely do the same to other jars. Also pretty sure the only way to get a 1.5 bytecode Tomcat is to compile from source :) Which if one enables the java5 USE flag on Gentoo. Not only can they run under 1.5 jre, but they are running 1.5 bytecode. Upstream binaries are 1.4 bytecode ;) -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
