Thanks Andrew. Someone on FedoraForum.org is starting to help shed a little light on the problem. He noticed a problem in the manifest of tomcat5's bootstrap.jar file. In the manifest he noticed this line: Class-Path: jmx.jar commons-daemon.jar commons-logging-api-1.1.1.jar tomcat-juli.jar
As a workaround, he executed this: ln -s commons-logging-api.jar commons-logging-api-1.1.1.jar
This workaround is less involved than combining the contents of two jar files.
I went looking for the same problem in tomcat6. However the manifest in bootstrap.jar doesn't even have a Class-Path element.
In your previous message you suggested filing a bug with the tomcat package and/or contacting the JPackage project. Does this new information narrow down where I should go next? I could also use a little help pointing me to where I should file a bug report. Is this where I'd file it for Tomcat? https://issues.apache.org/bugzilla/index.cgi And is this where I'd shoot the JPackage email? https://www.zarb.org/mailman/listinfo/jpackage-discuss
Thanks.
Hi,
* Greg Johnson gregjo@yahoo.com [2008-05-23 12:29]:
Class-Path: jmx.jar commons-daemon.jar commons-logging-api-1.1.1.jar tomcat-juli.jar
Ah, Class-Path entries in JAR manifests aren't allowed in Fedora packages:
http://fedoraproject.org/wiki/Packaging/Java#head-35dda923a0a2f82c349c3a998e...
In your previous message you suggested filing a bug with the tomcat package and/or contacting the JPackage project. Does this new information narrow down where I should go next?
Not really :) I suspect the change will be made at JPackage first and then imported into Fedora, but since I'm not sure where, I'd suggest filing a bug and asking on the jpackage mailing list.
Is this where I'd file it for Tomcat? https://issues.apache.org/bugzilla/index.cgi
No, file against the Fedora package at bugzilla.redhat.com.
And is this where I'd shoot the JPackage email? https://www.zarb.org/mailman/listinfo/jpackage-discuss
Yes.
Andrew
On Fri, 2008-05-23 at 13:45 -0400, Andrew Overholt wrote:
Hi,
- Greg Johnson gregjo@yahoo.com [2008-05-23 12:29]:
Class-Path: jmx.jar commons-daemon.jar commons-logging-api-1.1.1.jar tomcat-juli.jar
Ah, Class-Path entries in JAR manifests aren't allowed in Fedora packages:
http://fedoraproject.org/wiki/Packaging/Java#head-35dda923a0a2f82c349c3a998e...
I'm not too sure I understand the why of this though ? Isn't it a good to remove the burden of knowing what other .jars are required to make it work away from consuming apps. And maybe even use them as an input into an rpm autorequires sort of thing ?
C.
* Caolan McNamara caolanm@redhat.com [2008-05-23 14:09]:
On Fri, 2008-05-23 at 13:45 -0400, Andrew Overholt wrote:
Ah, Class-Path entries in JAR manifests aren't allowed in Fedora packages:
http://fedoraproject.org/wiki/Packaging/Java#head-35dda923a0a2f82c349c3a998e...
I'm not too sure I understand the why of this though ?
Here's what Nicolas Mailhot had to say during the Java Packaging guidelines process:
"the problem with classpathes-in-manifest is you hardcode the location of other jar files inside a file. So any common file operation like copying, renaming, moving the referenced file or the jar itself will break the classpath and trigger difficult-to-debug failures. When the classpath is in a single place and not hidden in part inside jar files maintenance is much easier and file operations do not require doing surgery inside jar files"
-- http://fedoraproject.org/wiki/Packaging/Java?action=recall&rev=34
Isn't it a good to remove the burden of knowing what other .jars are required to make it work away from consuming apps. And maybe even use them as an input into an rpm autorequires sort of thing ?
A Java module system would fix that properly. Examples include JSR 277 or OSGi. Supposedly will get something in the JRE/JDK with Java 7. I really don't know what I'm talking about here, though, so feel free to ignore me :)
Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Greg Johnson wrote: | Thanks Andrew. Someone on FedoraForum.org is starting to help shed a little light on the problem. He noticed a problem in the manifest of tomcat5's bootstrap.jar file. | In the manifest he noticed this line: | Class-Path: jmx.jar commons-daemon.jar commons-logging-api-1.1.1.jar tomcat-juli.jar | | As a workaround, he executed this: | ln -s commons-logging-api.jar commons-logging-api-1.1.1.jar
This is why classpaths in manifests are a bad idea. How easy was it to find that? And any upgrade of commons-logging would break tomcat5 even though the two packages are unrelated.
| This workaround is less involved than combining the contents of two jar files. | | I went looking for the same problem in tomcat6. However the manifest in bootstrap.jar doesn't even have a Class-Path element.
I would say that an incorrect classpath is wrong (and should even be removed), but an empty classpath is not.
While I am not sure if the fault lies with tomcat or eclipse, the eclipse plugin should place a symlink where it expects to find its libraries, so in that sense it's a packaging bug in the eclipse plugin.
- -- Sincerely,
David Walluck david@zarb.org
* David Walluck david@zarb.org [2008-05-23 15:17]:
While I am not sure if the fault lies with tomcat or eclipse, the eclipse plugin should place a symlink where it expects to find its libraries, so in that sense it's a packaging bug in the eclipse plugin.
Except the Eclipse plugin isn't a package and was installed via the update manager ...
Andrew
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Overholt wrote: | * David Walluck david@zarb.org [2008-05-23 15:17]: |> |> While I am not sure if the fault lies with tomcat or eclipse, the |> eclipse plugin should place a symlink where it expects to find its |> libraries, so in that sense it's a packaging bug in the eclipse plugin. | | Except the Eclipse plugin isn't a package and was installed via the | update manager ...
Then how can we support it?
We can only support the packages that we maintain that are properly packaged according to our policies.
- -- Sincerely,
David Walluck david@zarb.org
* David Walluck david@zarb.org [2008-05-23 17:29]:
We can only support the packages that we maintain that are properly packaged according to our policies.
If our tomcat packages are packaged that differently than upstream provides, and external projects rely on the upstream layout, I'd say our packages are broken.
Andrew
java-devel@lists.fedoraproject.org
-
Andrew Overholt -
Caolán McNamara -
David Walluck -
Greg Johnson