> I've been keeping an eye on the recent conversations about this and the > codebase service and didn't see the bit that said "If we swapped to Maven > repo, it would be better because..." I'm not saying it's not there, I just > can't/didn't see it. > > I'm not anti-Maven, I'm a Maven newbie (at best). I'd just like to be clear > on what problem this change is trying to solve. > > Also, Peter (I think) made the comment about providing an upgrade path for > those on Jini 2.1. Is it the intention that using Maven will remain > entirely optional, or will having a Maven repo become a requirement for > using River services?
It would be optional, as far as I've been following the conversation. What we're trying to address is how to avoid depending on a codebase service. If the JARs you need (e.g. -dl.jar) are already installed locally,then you can bypass the codebase download. The question is how we get the service to identify the resource in such a way that the client can determine if it's available locally. The local Maven coordinate system and repo is one out-of-the-box solution. For people who want to use it, it would mean they could push their artifacts out to one or more (e.g. clustered) Maven repos, and they would be pulled down to clients as needed; or they could just install the artifacts themselves to the local Maven client repos (there are command-line Maven tools to do this). The upside, I think, is that the codebase download is no longer a weak link in the chain of hooking up with a service, and certain trust issues are taken out of the equation. It should be optional, though; I imagine that when Sun finally polishes off the Jigsaw module work they've been doing an alternative would be to use the local Jigsaw module repository, for example. Patrick
