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?
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.
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.
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?
