|Summary:||juli.jar published twice in Maven repository|
|Product:||Tomcat 6||Reporter:||Marc Guillemot <mguillemot>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Marc Guillemot 2010-06-08 03:43:00 UTC
Exactly (look at the md5) the same juli.jar file is published two times with different groupdId in the Maven repository: First in: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/extras/juli/6.0.26/ with following groupId/artifactId <groupId>org.apache.tomcat.extras</groupId> <artifactId>juli</artifactId> and then in http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/juli/6.0.26/ with following groupId/artifactId <groupId>org.apache.tomcat</groupId> <artifactId>juli</artifactId> One of these artifacts is surely useless and shouldn't be uploaded to the Maven central repository. Tomcat's package splitting is already strange enough, no need to make it more complicated that it is already.
Comment 1 Rainer Jung 2010-07-13 14:03:23 UTC
Those artifacts should have been different. The artifacts for 6.0.28 are OK now.
Comment 2 Marc Guillemot 2010-07-14 03:04:31 UTC
In fact for 6.0.28 org.apache.tomcat.extras juli still contains the content of org.apache.tomcat juli. Is it intentional? This looks strange to me.
Comment 3 Rainer Jung 2010-07-14 05:04:18 UTC
I definitely don't know enough about maven, but I checked the following places: In directory /www/people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/tomcat of the ASF distribution host people.apache.org I find: $ ls -l extras/juli/6.0.28/juli-6.0.28.jar juli/6.0.28/juli-6.0.28.jar ... 62756 Jul 9 20:46 extras/juli/6.0.28/juli-6.0.28.jar ... 26484 Jul 9 20:45 juli/6.0.28/juli-6.0.28.jar And on the web I checked: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/juli/6.0.28/ juli-6.0.28.jar 09-Jul-2010 16:45 26K and http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/extras/juli/6.0.28/ juli-6.0.28.jar 09-Jul-2010 16:46 61K So the 2 jars are different and correct at least at those places. Don't know your source for the jars or your md5 or similar though :( Regards, Rainer
Comment 4 Rainer Jung 2010-07-14 05:15:52 UTC
... and the timestamps of the directories on people.apache.org are: ... 12 Jul 11 08:34 extras/juli/6.0.28/ ... 12 Jul 11 08:34 juli/6.0.28/ I don't know how long replication takes.
Comment 5 Marc Guillemot 2010-07-14 05:25:14 UTC
Seems that I haven't been clear in my question. I try again. http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/extras/juli/6.0.28/juli-6.0.28.jar contains classes from following packages: org.apache.juli org.apache.juli.logging org.apache.juli.logging.impl and http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/tomcat/juli/6.0.28/juli-6.0.28.jar contains classes from following packages org.apache.juli org.apache.juli.logging This means (as far as I can see, I haven't verified each single class file) that the classes from packages org.apache.juli and org.apache.juli.logging are in both jars. In other words, this means that the second jar is useless when you use the first one. Are these duplications intended?
Comment 6 Rainer Jung 2010-07-14 06:08:40 UTC
In previous versions of TC 6 the jars in the maven repos were indeeed *identical*. I assume you really referred to that problem when you wrote "Exactly (look at the md5) the same juli.jar" in your original report. The different observation you are now referring to, namely that some classes in the two jars are identical, is right and that's intended: The non-extras jar contains a self-contained implementation of Tomcat JULI logging linking directly to the JDK logging. The extras jars contain an alternative implementation, namely a repackaged commons-logging. The repackaging helps in avoiding conflicts with webapp provided commons-logging. More information is contained in the docs: http://tomcat.apache.org/tomcat-6.0-doc/logging.html Regards, Rainer
Comment 7 Marc Guillemot 2010-07-14 06:20:06 UTC
Thanks for the explanation. This packaging choice is a bit strange as a dependency between two jars without intersection would be a more "natural maven way" but why not...