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-35dda923a0a2f82c349c3a998edb321da544de33

> 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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

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-35dda923a0a2f82c349c3a998edb321da544de33

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.

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

* 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-35dda923a0a2f82c349c3a998edb321da544de33
>
> 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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

-----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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkg3F2kACgkQItObMyg2XCV7IgCeO4mr6IObgu gSDNUtVmjT+2Bi
E30AnjEhc/426Do0dZXtaF/JtTHfG4QM
=yCZq
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

* 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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

-----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>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iEYEARECAAYFAkg3NygACgkQItObMyg2XCVyPwCgntdULOivEE CNDnqJeLUuu21a
ezsAoKGL1p3O6tsj6x4nS1NrqbyqjWf0
=P79Y
-----END PGP SIGNATURE-----

--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list

* 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
--
fedora-devel-java-list mailing list
fedora-devel-java-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-java-list