2010/5/25 Peter Firmstone <[email protected]> > 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. > > I was working on the maven artifacts a while ago, and have that work still available in my (outdated) workspace. When I find some time (difficult lately) I'll contribute what I have. I remember I was able to build Maven artifacts for just about any River JAR.
> > 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 have raised the same concern earlier. The Class-Path mechanism conflicts with a number of things, including Maven ... > 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. >> >> > 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. > > Similarly, I was working on integrating that piece of code into the River codebase before. However there was some problem with it. I'll (again) dig into my workspace and get more details. > > 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. > > Completely agree. Some form of restructuring/modularization has been preformed already, but there is certainly room for more of the same. > I tend to treat everything like an experiment, I'm free to change my mind > if something's not working out or if someone's got a better suggestion, > doing that instead. I think many people have fears about what might happen, > however that leads to paralysis, so we're better of trying something, > learning, then trying again. Usually people want to change something > because there's an underlying issue, we need to identify that issue and > weigh up the solution as it develops. What you conceive in the beginning > and what you end up with are always different anyway. > > Cheers, > > Peter. > > -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? >>> >>> >>> >>> >> >> >> > >
