Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Maven jar manifests
Date: Tue, 25 May 2010 17:46:17 -0400
Message-ID: 
 <77F1E32F67C8D5479858C0C7E93EB4656C834E@WAL-MAIL.global.avidww.com>
In-Reply-To: <4BFC3AB5.20805@wonderly.org>
Thread-Topic: Maven jar manifests
Thread-Index: Acr8TZqbCM/n9pAnRuO+fXK9hI00EQABdrQw
References: <4BFB4E8D.9020807@zeus.net.au>
 <AANLkTilA59i1Jy8a1TkJwYllFxJzBLHEL7IP7iezajwM@mail.gmail.com>
 <4BFBA7BD.5040209@zeus.net.au>
 <9E16B842-0E5C-401F-93BE-BD2059CE365D@gmail.com>
 <4BFC3AB5.20805@wonderly.org>
From: "Christopher Dolan" <christopher.dolan@avid.com>
To: <river-dev@incubator.apache.org>

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:gregg@wonderly.org]=20
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
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.
>>> =20
>> I don't know, does someone on the list have the answer?
>=20
> I would suggest that we advise that embedded Class-Path manifest=20
 > 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=20
(java -jar) and doing things simple enough that a startup
script/modularization=20
is not needed.  But, as soon as you start deploying things into an
environment=20
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=20
jar being in dist.  This seems convenient enough.  But wait until you
have A.jar=20
-> 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=20
makes a lot of sense to just not use Class-Path, and compose the
appropriate=20
URLClassLoader/PreferredClassLoader URLs as part of the deployment
packaging=20
step so that you can account for where each jar will actually be sourced
from,=20
including the difference between somethings coming from maven and others
coming=20
from a web server etc.

Gregg Wonderly