river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Maven jar manifests
Date Tue, 25 May 2010 21:01:41 GMT
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

Mime
View raw message