rpmlint problem: Class-Path in manifest problem

[alcapcom]

Hi,

My 0.01 $ idea.

1) Remove the CLASSPATH entry from the jar file, copy  the modify jar
in /usr/share/java/ant/.

2) Crea in /etc/ant.d that contain its like that (oro example)
oro ant/ant-apache-oro

If the task depend on many jars:
jar1 jar2 ant/task.jar

file place in /etc/ant.d help Ant to load the jars files in the CLASSPATH.

3) If it work, create a patch to remove the classpath line in the
manifest file, to do that at rpm build time.

4) Hope that Help you ;-)

Cheers
Alphonse


2006/7/12, Nicolas Mailhot <nicolas.mailhot at laposte.net>:
> Le mercredi 12 juillet 2006 à 14:43 -0500, Jason L Tibbitts III a
> écrit :
> > >>>>> "IF" == Igor Foox <ifoox at redhat.com> writes:
> >
> > IF> Does anybody know what this mean,
> >
> > > rpmlint -I class-path-in-manifest
> > class-path-in-manifest :
> > The META-INF/MANIFEST file in the jar contains a hardcoded Class-Path.
> > These entries do not work with older Java versions and even if they do work,
> > they are inflexible and usually cause nasty surprises.
> >
> > IF> and why it's considered bad?
> >
> > I don't know enough about Java to say more.
>
> Because the file will behave differently depending where it or its deps
> are in the filesystem, which leads to very unfunny debugging sessions to
> find out why an app suddenly broke.
> At lease when the classpath is in a script and not burried inside
> metadata you can understands what happens (plus scripts are a boatload
> more flexible than hardcoded absolute paths)
>
> --
> Nicolas Mailhot
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.4 (GNU/Linux)
>
> iEYEABECAAYFAkS1WBcACgkQI2bVKDsp8g3d5ACfS++VksQrm/Jusn+bvYAl8ROa
> /P4An3BgsFmlznSq0YYkgM8tNQ6y983r
> =MjP4
> -----END PGP SIGNATURE-----
>
>
> --
> fedora-extras-list mailing list
> fedora-extras-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-extras-list
>
>
>