Do we need to replace them? What with? Sounds like their use should be
strongly discouraged.
Peter.
Christopher Dolan wrote:
I strongly agree. Manifest Class-Paths have always caused problems for
my team in the context of Jini/River codebases. Furthermore, Eclipse
doesn't handle them very well (getting better in 3.5, but still broken).
Chris
-----Original Message-----
From: Gregg Wonderly [mailto:[email protected]]
Sent: Tuesday, May 25, 2010 4:02 PM
To: [email protected]
Subject: Re: Maven jar manifests
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
