Dennis Reedy wrote:
On May 25, 2010, at 634AM, Peter Firmstone wrote:
Jeff Ramsdale wrote:
1) Is there an issue with Jini's use of the Class-Path jar manifest
headers in the context of Maven? That is, is the Class-Path header
used in a number of the jars just a hint or does it have security
implications or some-such? The reason I ask is depending on how Maven
is used it could be possible to build a classpath from a Maven
repository in which jars are not positioned in the filesystem relative
to each other in a way that is reflected in the jars' manifests. For
instance, a service container could choose to build a runtime
classpath (including core Jini/River jars) directly from a local Maven
repo and the structure of the Maven repo would not match the jar
manifests as currently built.
I don't know, does someone on the list have the answer?
I would suggest that we advise that embedded Class-Path manifest
> headers not be used, and the resolution of a jar's dependencies are
> based on the declared dependencies in the pom.
The Class-Path manifest feels convenient when you are running stuff out of jars
(java -jar) and doing things simple enough that a startup script/modularization
is not needed. But, as soon as you start deploying things into an environment
where there are varied components in different places, things start to get messy.
For example, netbeans puts all of your dependent jars into dist/lib with your
jar being in dist. This seems convenient enough. But wait until you have A.jar
-> B.jar -> C.jar and A.jar -> D.jar -> B.jar. Then, you suddenly have
A.jar
lib/B.jar
lib/lib/C.jar
lib/D.jar
lib/lib/B.jar
being referenced by the codebase class loading. And it can get worse. So, it
makes a lot of sense to just not use Class-Path, and compose the appropriate
URLClassLoader/PreferredClassLoader URLs as part of the deployment packaging
step so that you can account for where each jar will actually be sourced from,
including the difference between somethings coming from maven and others coming
from a web server etc.
Gregg Wonderly
