On May 25, 2010, at 634AM, Peter Firmstone wrote: > Jeff Ramsdale wrote: >> 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. >> > > It needs someone willing to do it, I'm not in a position to make a judgement, > I don't have maven experience, I'm certainly not about to knock back > contributions or offers of help, if someone has the experience and is willing > to follow though, I'm happy to learn. I'd take on a small project conversion > to maven myself and learn, but not something the size of River straight up. > >> 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. > >> 2) As Dennis mentioned on another thread, should classdepandjar ( >> https://classdepandjar.dev.java.net/ ) be used? Should it be converted >> to Maven? Thats already been done with the Rio plugin (http://www.rio-project.org/classdepandjar-mojo.html), I thought you were using it? :) River is most welcome to it if the project would like it. >> 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. Is the refactored ClassDep released? >> > Wow, I didn't even know this existed, definitely get in touch see if Chris is > happy to donate the code, we can look at both, lets see what we can learn. > >> 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. >> > > Is it going to make the codebase easier to maintain? If your talking about > making the platform more modular, eg, each platform service could be it's own > subproject or something like that, provided we can provide a migration path > for existing Jini 2.1 users then that has to be a plus. I've thought about > this sort of modularisation and for those not wanting to do separate > downloads for components, we can distribute a complete zip artifact. I think > if your considering ease of development and improving the application > development experience then I'm all for it. I think net.jini.* has to be > evolved with backward compatibility in mind, however com.sun.* is your oyster. The maven project restructuring would indeed allow each service to be a sub-module. Unless we choose to change the names of the produced artifacts to align themselves with the newly discussed conventions, I dont see issues with backwards compatibility, because the contents of the jars would be the same. I would also suggest that if you go down this route, you would want to move from the com.sun.jini namespace to the org.apache.river namespace. A big (and lingering) question to me is how to integrate the current test framework into a maven project, or to do it at all.
