On May 22, 2010, at 717AM, Patrick Wright wrote: > Hi > > On Sat, May 22, 2010 at 12:38 PM, Peter Firmstone <[email protected]> wrote: >> Since we've got a few Maven people on the list how should we best approach >> utilising the Maven repository? >> >> Patrick, have you got something in mind for a Codebase Entry? > > I'll just brainstorm here a bit. Let's keep the example simple to > start with: a service has registered itself in the LUS, and has entry > meta-data indicating which JAR files must be on the classpath, or must > be downloaded (the "impl" JAR, or -dl.jar files). Let's assume that > these JAR files have already been installed in the Maven repository of > the local, client, machine. In Maven terminology, we want the service > to specify the coordinates[1] to the artifacts required;
In general the DL jar is derivable if you know the service's main artifact (the impl jar). The way we've done this is to simply use a "dl" classifier to distinguish the DL jar (and "ui" classifie for the ui jar). The same can be done for the api jar as well. Something to think about up front is that you also need to figure out how to build a service using maven, especially since with a Jini type system a service has multiple artifacts, up to 4 (impl, dl, ui, api). If you're interested in work thats been completed surrounding these areas, please check out http://www.rio-project.org/resolver.html and http://www.rio-project.org/classdepandjar-mojo.html for info on utilities surrounding the construction and resolving of artifacts. I only mention this because it may help refine some thoughts and goals you're trying to achieve here. If anything makes sense for you to use, I'd be glad to help. > these > coordinates need to be present in an array of Entry instances in the > service registration > > MavenBasedServiceEntry { > public MavenCoordinateEntry[] coordinatesToRequiredArtifacts; > } > > MavenCoordinateEntry { > public String groupId; > public String artifactId; > public String version; > public String classifier; > public byte[] optionalArtifactHash; > public int optionalHashConstantIdentifier; // e.g. SHA1 > } > > I would just go with a List<String> dlJars; With this you could provide support for retrieving the DL jar(s) for non-maven systems as well. If the dlJars property contains 1 element and is of the form groupId:artifactId:version:classifier, then maven resolution gets used. Otherwise the DL jars can be obtained using the codebase of the advertising service. For maven resolution, I think you'll also want to either provide support for parsing your maven settings.xml or include the repositories to go find the artifact if it's not present. If the artifact is retrieved from the repository it will have a message digest along side of it (with either a .sha1 or .md5 extension). That can be used to compare a locally computed digest HttpmdUtil.computeDigest() for updates. But that comparison really only needs to take place for snapshots, since by definition releases are considered immutable. IMO supporting transitive deps is a must have, without that we really dont get that far. A DL artifact may depend on another DL artifact, and that DL artifact may have deps as well.
