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: https://issues.apache.org/jira/browse/RIVER-317
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 else. 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. -jeff On Mon, May 24, 2010 at 9:14 PM, Peter Firmstone <[email protected]> wrote: > Do we have someone willing to create some ant scripts to build the Maven > Manifests for River's jar files? > >
