Hi
On Sat, May 22, 2010 at 12:38 PM, Peter Firmstone <j...@zeus.net.au> 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; 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
}
Normally, the coordinates are converted into a path relative to a
"local Maven repository". The local repository installs by default to
~/.m2/repository, though when using the Maven tools the location can
be overridden with a property setting. River should probably also
allow overriding this location.
The group id is normally a Java package name, e.g. net.jini or
com.sun.jini. The dots are converted to directory separators. The
artifact name is another directory, the version is yet another, and
the classifier is usually appended to the end of the artifact name.
Note that classifier is often left out and can be used when you
publish different artifacts for a single module. So if I need
commons-io 1.3.2, the path would be
~/.m2/repository/org/apache/commons/commons-io/1.3.2/commons-io-1.3.2.jar
The artifact (commons-io-1.3.2.jar) may or may not have a version
number in the name; it's up to the package distributor to decide.
In this simple case, if you assume the artifacts are already
downloaded locally, you just need to read the entry instances and
build a class path entry pointing to the JAR file. It's common, but
not required, for a hash file to be included in the distribution,
which could be used for verification.
Phase 2 would be to use the Maven machinery to download the file if it
isn't present locally. You can configure your local Maven settings
with a list of remote repositories to query for the artifact. I don't
think I would include that in River itself, but it may be nice for
people to know how to bind it in if they need it. It simplifies
distribution, because the deployment manager just pushes the artifact
to an upstream repository, and clients synchronize those artifacts to
their local repositories lazily, when they first need them. River
could use the embedded Maven support to handle this synchronization,
as a pluggable utility.
Phase 3 might be adding support for transitive dependencies. This
would be helpful for cases where the -dl.jar/impl required 3rd-party
libraries that might not be present in the client already. I'm
hesitant to say you should support automatic transitive dependency
resolution, which Maven supports, as it's not always perfect--you
sometimes include much more in your classpath than is really needed
because the dependency lists upstream haven't been properly
maintained. A better approach would be just to include those in the
Entry array as separate items.
I think adding support for using the Maven repository is at least a
short-term win. However, in the wider open-source JVM community there
is a good deal of anti-Maven sentiment, although some build tools
(Groovy has one, and Clojure as well) use their own configuration
system but rely on the Maven repositories for artifact management,
just because so much of the infrastructure is already in place and
there is such a mass of 3rd-party libraries already available in Maven
repositories online. I mention this because medium term, if for River
you decide that the coordinate system is a decent way of uniquely
identifying an artifact, then the resolution from coordinate to local
path can be handled in various ways, e.g. it's just a Strategy that
can be selected by the developer.
There are a few corner cases to handle which we can discuss later.
Anyway, this is a bit of brainstorming on how I think this might work.
I think it's enough to prototype with.
Regards
Patrick
[1] http://maven.apache.org/pom.html#Maven_Coordinates
