2010/5/25 Christopher Dolan <[email protected]> > 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). >
Exactly. There's all sorts of headaches with Class-Path. > 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 >
