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. It also enables us to use alternative implementations and switch them without changing all dependent applications (though this is less important/needed). The rule has been around for a long time so I guess there might be other reasons as well. In my head the reasoning sounds like this: A: Can we make Class-Path work in most (let's say 90%) of cases? B: No, we'd have to modify manifests on the fly with some ugly scripts A: Ok, so let's just simplify and get rid of it That said, I would be possible to create jar files with correct Manifests with XMvn. That way maintainer wouldn't have to do much (if anything). There are probably good reasons not to do this though. -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
