[fedora-java] Why no Class-Path manifest attribute?

[Florian Weimer]

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