Java packaging questions about rpmlint messages

[Bruno Wolff III]

I am working on packaging a java game and have a couple of rpmlint messages
that I am not sure if I can ignore.

One is an error for having no binaries. I thought the java stuff was somewhat
arch dependent, so I thought my resulting jar file should be arch dependent
and that overriding the buildarch would be a bad idea?

The second is a warning for including a classpath in the manifest. The original
package is setup to have a class path point to a library with a few included
jar files. Only one of these jars is needed and is already packaged for
Fedora. For the build process I override the property saying where the libs
are to point to the Fedora jar directory. But this gets left in the manifest.
To run the program I have a shell script that includes the two jar files
and gives the class name to run. So while not being able to give a usable
classpath on the java command line is annoying, it isn't a big deal in this
case. Is this out and out broken? Is there a way to do it better without
having to do too much customization of the original projects build.xml
file? (ant is used to do the build.)

[Susi Lehtola]

On Sun, 2009-06-28 at 17:48 -0500, Bruno Wolff III wrote:
>  I am working on packaging a java game and have a couple of rpmlint
> messages
>  that I am not sure if I can ignore.
>  
>  One is an error for having no binaries. I thought the java stuff was somewhat
>  arch dependent, so I thought my resulting jar file should be arch dependent
>  and that overriding the buildarch would be a bad idea? 
The whole idea of Java is build once, run on everything. Java is noarch
(at least when not compiling with gcj).

>  The second is a warning for including a classpath in the manifest.
> The original
>  package is setup to have a class path point to a library with a few included
>  jar files. Only one of these jars is needed and is already packaged for
>  Fedora. For the build process I override the property saying where the libs
>  are to point to the Fedora jar directory. But this gets left in the manifest.
>  To run the program I have a shell script that includes the two jar files
>  and gives the class name to run. So while not being able to give a usable
>  classpath on the java command line is annoying, it isn't a big deal in this
>  case. Is this out and out broken? Is there a way to do it better without
>  having to do too much customization of the original projects build.xml
>  file? (ant is used to do the build.) 
You need to remove the included .jars and classpaths and make the
package use the packages in Fedora (or package the requirements in
Fedora if it's missing at the moment).
-- 
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org

[Bruno Wolff III]

On Mon, Jun 29, 2009 at 08:31:00 +0200,
  Jussi Lehtola <jussilehtola(a)fedoraproject.org&gt; wrote:
>  On Sun, 2009-06-28 at 17:48 -0500, Bruno Wolff III wrote:
>  > I am working on packaging a java game and have a couple of rpmlint messages
>  > that I am not sure if I can ignore.
>  > 
>  > One is an error for having no binaries. I thought the java stuff was somewhat
>  > arch dependent, so I thought my resulting jar file should be arch dependent
>  > and that overriding the buildarch would be a bad idea?
>  
>  The whole idea of Java is build once, run on everything. Java is noarch
>  (at least when not compiling with gcj). 
I know that's the idea in theory. I wasn't planning on restricting the
rpm to just using openjdk. So in that case do I need to allow normal
arch stuff?

>  > The second is a warning for including a classpath in the
> manifest. The original
>  > package is setup to have a class path point to a library with a few included
>  > jar files. Only one of these jars is needed and is already packaged for
>  > Fedora. For the build process I override the property saying where the libs
>  > are to point to the Fedora jar directory. But this gets left in the manifest.
>  
>  You need to remove the included .jars and classpaths and make the
>  package use the packages in Fedora (or package the requirements in
>  Fedora if it's missing at the moment). 
The included jar files have been removed. I change the property that is used
to build the class path to point to the Fedora version of the need jar
file (jdom) for building purposes. However after the build the resulting
jar file still has a manifest with a classpath in it. It seems like the
only downside is you can't override the classpath when using the -jar option
to run the jar file. That's really the issue. It isn't using anything that
isn't built in Fedora.

[Ville Skyttä]

On Monday 29 June 2009, Bruno Wolff III wrote:

>  The included jar files have been removed. I change the property that
> is
>  used to build the class path to point to the Fedora version of the need jar
>  file (jdom) for building purposes. However after the build the resulting
>  jar file still has a manifest with a classpath in it. 
It should be trivial to get rid of that as well, just search for a MANIFEST.MF 
template used or the build.xml section that generates it, and patch it out.

>  It seems like the
>  only downside is you can't override the classpath when using the -jar
>  option to run the jar file. That's really the issue. 
It may cause other nasty and hard to debug surprises if another app uses the 
jar.  Class-Path entries in jar manifests are kind of like RPATHs and should 
be avoided for the same reasons, at least for jars installed in system jar 
paths (e.g. /usr/share/java).  
https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath

[Bruno Wolff III]

On Mon, Jun 29, 2009 at 19:11:55 +0300,
  Ville Skyttä <ville.skytta(a)iki.fi&gt; wrote:
>  On Monday 29 June 2009, Bruno Wolff III wrote:
>  
>  > The included jar files have been removed. I change the property that is
>  > used to build the class path to point to the Fedora version of the need jar
>  > file (jdom) for building purposes. However after the build the resulting
>  > jar file still has a manifest with a classpath in it.
>  
>  It should be trivial to get rid of that as well, just search for a MANIFEST.MF 
>  template used or the build.xml section that generates it, and patch it out.
>  
>  > It seems like the
>  > only downside is you can't override the classpath when using the -jar
>  > option to run the jar file. That's really the issue.
>  
>  It may cause other nasty and hard to debug surprises if another app uses the 
>  jar.  Class-Path entries in jar manifests are kind of like RPATHs and should 
>  be avoided for the same reasons, at least for jars installed in system jar 
>  paths (e.g. /usr/share/java).  
>  https://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath 
OK. It sounds like I need to fix this then (even though I don't expect the
jar to get used by any other packages). I'll deal with it before I submit
the package for review. (I also need to deal with some artwork issues before
I can submit it.)

Thanks for the advice.