Sorry to open up with venting, but I truly cannot believe how big of a
mess that I found of Tomcat's and others' jars under /usr/share/java in
a CentOS 5.2 distribution I examined this morning.
For years I've been using tar.gz'd Tomcat that I downloaded and
applications I used that had standalone installs would provide similar
looking directory layouts of Tomcat. All of those were just great.
In the RPM'd Tomcat though, the directories are spread out all over the
place (which is acceptable), but from what I've been told, the
backporting of patches and possibly attempts to lower the number of the
same files (jar files in this case) leave you with a ton of sometimes
insane looking symlinks and files.
Here is what I'm talking about in /usr/share/java if you're unfamiliar:
libgcj-4.1.1.jar
libgcj-4.1.2.jar -> libgcj-4.1.1.jar
libgcj-tools-4.1.1.jar
libgcj-tools-4.1.2.jar -> libgcj-tools-4.1.1.jar
Regardless of how trivial a small change in a version of a jar might be
in one case for one version of an application, since this is a shared
area for jars, you don't know what some other application would expect
out of that jar. And if the person trying to track down an issue thinks
they are using one version of a jar, but it is really pointed at a
different version.
xerces-j2.jar -> xerces-j2-2.7.1.jar
This seems wrong because you can't assume that, just because you are
dependent on a certain jar in one application, the same one would apply
to multiple applications. One app might be built with 2.7.1 and another
with 2.7.3 that didn't deprecate some method that it removed or changed
the signature of, and you might not notice that unless every facet of
the jar were tested, and if RedHat or the Fedora community has enough
time to do that, they certainly aren't spending their time very wisely.
wsdl4j.jar -> qname-1.5.2.jar
This just looks completely wrong, even if they completely merged the
same version of the previous jar into the new one:
and
servletapi5.jar -> tomcat5-servlet-2.4-api-5.5.23.jar
This seems wrong on a new counts here as it is a specific implementation
and specific version paired with a generic jar name symlink. this one is
more excusable than the others though.
I don't fundamentally disagree with things often, but I really don't
agree that this is a good idea, and it is unfortunately one of the worst
messes of jars/dependencies I've seen in my last 10 years as a Java
developer (and I've seen some pretty messed up things).
How and why could someone RPM Tomcat at all if this is the mess that it
falls into?
TIA for any comments, facts, or opinions you can provide,
Gary
Please note that I also just wrote a quick entry about this here (feel
free to comment there if you'd rather, although they shut it down for
comments after a while to avoid blog link spamming):
http://weblogs.java.net/blog/garysweaver/archive/2009/05/peering_into_th.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
