river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Dolan" <christopher.do...@avid.com>
Subject RE: Maven jar manifests
Date Tue, 25 May 2010 21:46:17 GMT
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).


-----Original Message-----
From: Gregg Wonderly [mailto:gregg@wonderly.org] 
Sent: Tuesday, May 25, 2010 4:02 PM
To: river-dev@incubator.apache.org
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
>>> is used it could be possible to build a classpath from a Maven
>>> repository in which jars are not positioned in the filesystem
>>> 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
>>> 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
is not needed.  But, as soon as you start deploying things into an
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
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


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
URLClassLoader/PreferredClassLoader URLs as part of the deployment
step so that you can account for where each jar will actually be sourced
including the difference between somethings coming from maven and others
from a web server etc.

Gregg Wonderly

View raw message