On 05/27/2013 06:08 PM, Stanislav Ochotnicky wrote:
Quoting Florian Weimer (2013-05-27 15:01:38)
It seems that a significant number of JAR files under /usr/share/java do
not declare their dependencies using the Class-Path manifest attribute.
As a result, the dependencies need to be collected manually and included
with the final link (typically, in the -classpath argument to
/usr/bin/java). This is mightily inconvenient and leaks implementation
details across Java RPM package boundaries. (I don't think
%jpackage_script does recursive linking, unlike the JVM.)
rpmlint flags usage of the Class-Path attribute:
http://fedoraproject.org/wiki/Packaging:Java#class-path-in-manifest
But why?
Since nobody replied, I will try...
Because in 99.9% percent of cases this Class-Path attribute would be incorrect.
It has to be generated/added during build, but at that time it's unknown where
those dependent jar files end up on the filesystem.
But that's because the policy encourages to make the paths non-predictable:
"If a project offers the choice of packaging it as a single monolithic
jar or several ones, the split packaging should be preferred."
"Alternatively, the file can be installed to the subdirectory
%{_javadir}/%{name}/ under its usual name."
"Packages CAN place JAR files into subdirectories."
"If the package provides more than one JAR file, the filenames assigned
by the build MUST be used (without versions)."
You need stable JAR names at well-defined locations for valid Class-Path
references. The benefits of unpredictable naming of JAR files are less
clear to me.
The rule has been around for a long time so I guess there might be other reasons
as well.
The existence of the Class-Path attribute is not widely known, and I was
surprised to see it mentioned in the policy.
My experience using it for dependency management has been extremely
positive. It certainly was less error-prone than guessing dependencies
manually. (I remember one case where a JAR file was inadvertently put
on the classpath which replaced some system XML parser with an HTML
parser. Yuck.)
--
Florian Weimer / Red Hat Product Security Team
--
java-devel mailing list
java-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/java-devel
