river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Ramsdale <jeff.ramsd...@gmail.com>
Subject Re: Maven jar manifests
Date Tue, 25 May 2010 05:41:31 GMT
I provided some poms awhile back that were checked in, but there were
some very reasonable questions raised about how (in particular) dl
jars should be treated in Maven. See:

At the time there didn't seem to be a definitive answer with respect
to Apache River. Now that the conversation around Maven and River is
occurring I think we'll see something emerge. If so, and if it might
be the preferable way to write River services, shouldn't River itself
be built with Maven? Either way I'd be glad to help but I'm about to
leave for vacation for a week. Meanwhile the conversation can continue
and I'll attempt to monitor...

If converting the build to Maven is of interest (and I'd recommend it)
there are a few issues I'd raise.

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.

2) As Dennis mentioned on another thread, should classdepandjar (
https://classdepandjar.dev.java.net/ ) be used? Should it be converted
to Maven? Chris Sterling did something similar with the Maven Classdep
Plugin ( https://maven-classdep-plugin.dev.java.net/ ) but I don't
know if it ever functioned 100%. If there's interest I could contact
him to revive it (he's a friend) or, alternatively, River could
provide its own Maven plugin (perhaps in conjunction with the
Archetype(s) Dennis suggested). In any case, whatever solution is
selected should definitely use the updated Classdep that doesn't
depend on Sun's tools.jar. I see that as a prerequisite for everything

3) To what degree would a further restructuring of the code be of
interest? I don't necessarily have specific ideas here (yet), but it
seems like we're finally free to begin to move things around in a way
that would serve the project's goals and it would be good to have the
conversation first.


On Mon, May 24, 2010 at 9:14 PM, Peter Firmstone <jini@zeus.net.au> wrote:
> Do we have someone willing to create some ant scripts to build the Maven
> Manifests for River's jar files?

View raw message