Bug#685298: Impossible to simultaneously install libtomcat7-java and libtomcat6-java

Loyall, David david.loyall at nebraska.gov
Fri Sep 13 15:06:36 UTC 2013


I'm in favor of option 2: don't put tomcat libs in /usr/share/java, much less unversioned ones.

When was the last time anybody looked in /usr/share/java when they wanted to build or run anything? :)

It seems to me that the real users of the tomcat* packages are developers.

Sure, there could be some package foo-game that runs in (and depends on) tomcat.  In that case, I think it's up to the foo-game maintainer to make sure her package works, and as a java developer, she's probably disinclined to look in /usr/share/java, too.  (Of all the mailing lists in the world, this is the one where I'll find the most disagreement with the previous statement!)

You see where I'm going here?  To get Java to be a first class citizen in the Debian ecosystem is going to take more than deciding where to store some jars.  ...And the more friendly we are to java developers in the meantime, the more help we'll have during that long journey.

I hope this helps.

Regarding the long road ahead, has anybody ever considered providing a Debian specific classloader?  Thought experiment: How would you meet Debian needs and Java needs simultaneously if the only thing you had control of was the classloader?

Cheers,
--Dave

> -----Original Message-----
> From: Emmanuel Bourg [mailto:ebourg at apache.org]
> Sent: Friday, September 13, 2013 6:19 AM
> To: 685298 at bugs.debian.org
> Cc: tony mancill; Loyall, David; Jakub Adam
> Subject: Re: Bug#685298: Impossible to simultaneously install libtomcat7-java
> and libtomcat6-java
> 
> Hi,
> 
> I started working on the tomcat8 package and I'd like to avoid the same
> conflict with tomcat7. What would be the best solution?
> 
> 1. Change the name of the unversioned jars to tomcat8-xxx.jar. That would
> give the following links in /usr/share/java:
> 
>     tomcat8-catalina-ant.jar -> tomcat-catalina-ant-8.0.0.jar
>     tomcat8-catalina-tribes.jar -> tomcat-catalina-tribes-8.0.0.jar
>     tomcat8-annotations-api.jar -> tomcat-annotations-api-8.0.0.jar
>     tomcat8-api.jar -> tomcat-api-8.0.0.jar
>     tomcat8-catalina-ha.jar -> tomcat-catalina-ha-8.0.0.jar
>     tomcat8-catalina.jar -> tomcat-catalina-8.0.0.jar
>     tomcat8-coyote.jar -> tomcat-coyote-8.0.0.jar
>     tomcat8-i18n-es.jar -> tomcat-i18n-es-8.0.0.jar
>     tomcat8-i18n-fr.jar -> tomcat-i18n-fr-8.0.0.jar
>     tomcat8-i18n-ja.jar -> tomcat-i18n-ja-8.0.0.jar
>     tomcat8-jasper-el.jar -> tomcat-jasper-el-8.0.0.jar
>     tomcat8-jasper.jar -> tomcat-jasper-8.0.0.jar
>     tomcat8-juli.jar -> tomcat-juli-8.0.0.jar
>     tomcat8-util.jar -> tomcat-util-8.0.0.jar
> 
> 2. Move the jars and links in a subdirectory of /usr/share/java.
> 
>     /usr/share/java/tomcat8/tomcat-juli.jar -> ./tomcat-juli-8.0.0.jar
>     /usr/share/java/tomcat8/tomcat-util.jar -> ./tomcat-util-8.0.0.jar
> 
> 3. Don't put the unversioned links in /usr/share/java. If a reverse
> dependency requires a stable path for building it could use the Maven
> repository in /usr/share/maven-repo. The Maven based packages wouldn't
> be impacted, and the Ant based packages could use a path like:
> 
> 
> /usr/share/maven-repo/org/apache/tomcat/tomcat-jasper/8.x/tomcat-
> jasper-8.x.jar
> 
> What do you think?
> 
> Emmanuel Bourg



More information about the pkg-java-maintainers mailing list