I agree with Patrick on this point. It almost certainly requires a new type of Entry such as Partick's CoordinateArtifactEntry example. How many developer hours might be lost because of some typo in a string that needs to be structured and decoded in some way! :-)
One thing that I didn't see (can someone point it out, using small words please) how using Maven repositories makes is easier/better/faster/whatever for someone? Also, who is that someone, service developers or the support teams for those services? 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? Cheers, Tom On Tue, May 25, 2010 at 1:12 PM, Patrick Wright <pdoubl...@gmail.com> wrote: > >> Yes, we can use an Entry, or as Chris pointed out, if we annotate > MarshalledInstance's using a new Maven URL schema we can extract that info > and make it available via MarshalledServiceItem (An abstract class that > extends ServiceItem). > > > > I dont think a new Maven URL schema has actually been proposed? Why > wouldnt we just use a String attribute in an Entry that is of the form > groupId:artifactId:version:classifier? > > What I don't like about this is that it makes the client a little more > fragile--we would essentially be sniffing a string for a certain > format, which, if it matched, would indicate it is a Maven coordinate. > If this is in a separate type of Entry (e.g. CoordinateArtifactEntry > or so) then we are reacting to a type of entry, not to a format which > needs to be documented, etc. > > > Patrick >
