I don't totally understand how maven resolves snapshot dependencies
but I think we should try to mimic its behavior as much as possible
since the plugins come from a maven repository, and are typically put
there by "mvn deploy". Based on some very simple testing it looks
like when maven downloads a snapshot dependency it consults maven-
metadata.xml (and maybe some other xml files) from the repo to get
the actual jar name. The jar name might include extra stuff like the
timestamp and build number. Then it downloads that jar into the
local repo and adds it to the build classpath. I think the plugin
installer can mimic that behavior (and basically already does) up to
the point where the jar is added to the classpath and Geronimo
recognizes the dependency as being satisfied.
We could change Geronimo's dependency resolution code to act more
like maven, where a dependency called out like, say,
mygroup/myartifact/1.0-SNAPSHOT/jar
is actually satisfied by a jar at :
geronimo/repository/mygroup/myartifact/1.0-SNAPSHOT/myartifact-
<whatever version maven said to download>.jar
But I don't know a lot about that code and it hurts my head to think
about all the potential side effects.
So unless someone wants to grab that tiger by the tail maybe the
plugin installer should instead mimic the behavior of maven right up
to the point where the downloaded jar is copied into the Geronimo
repository. At that point it could name the jar to match the
original dependency name, instead of whatever name was determined by
following maven's process for resolving snapshot dependencies.
After all the jar that is being downloaded (whatever its name) is
what maven considers to be a match for the requested dependency.
Taking this approach would mean that a dependency like this in the
plugin xml:
mygroup/myartifact/1.0-SNAPSHOT/jar
might result in this file being downloaded from the maven repo:
mygroup/myartifact/1.0-SNAPSHOT/myartifact-<whatever version
maven-metadata.xml said to download>.jar
but it would be placed here in the geronimo repo:
geronimo/repository/mygroup/myartifact/1.0-SNAPSHOT/
myartifact-1.0-SNAPSHOT.jar
so that Geronimo's dependency resolution doesn't have to become more
aware of how the maven metadata has caused the plugin installer to
resolve the snapshot. This is basically the approach I had suggested
in our IRC chat.
Best wishes,
Paul
On Aug 8, 2007, at 3:13 PM, Vamsavardhana Reddy wrote:
I have encountered some unexpected things while trying to install a
plug-in when SNAPSHOT versions are specified as dependencies. Here
are some examples:
1. A query for "foo/bar/1.0-SNAPSHOT/jar" of an artifact from a
remote repository returned result "foo/bar/1.0-beta1/jar". The
plug-in installer downloaded 1.0-beta1 and installed in server's
repository. Plug-in startup failed since 1.0-SNAPSHOT is not
available in server's repository.
2. A second attempt to install the same plug-in (after uninstalling
the one installed but not started in (1) above), goes through the
same steps for downloading "foo/bar/1.0-SNAPSHOT/jar" and downloads
"foo/bar/1.0-beta1/jar". But this time it failed with an error
unable to copy dependency since it is already in the server's
repository!! (downloaded
3. A query for "1.0-incubating-SNAPSHOT" version of a tuscany
artifact had resulted in "0.91-incubating". I do not remember the
exact artifactId.
Problem in (2) can be addressed by checking to see if result
version is already in server's repository and avoid downloading
it. It has been fixed in rev 563782 (branches\2.0) and 563785
(trunk).
Regarding problem in (1), I had a discussion with Paul McMahan on
IRC and we decided that if a query for a version of artifact
results in a different version, then we will indeed copy the
downloaded result into server's repository under query version.
(In our example, though we download "foo/bar/1.0-beta1/jar", we
will copy it as "foo/bar/1.0-SNAPSHOT/jar ". This way we will
avoid plug-in startup failure.) Since we copy the artifact under
a SNAPSHOT version, there is no harm as two artifacts named "foo/
bar/1.0-SNAPSHOT/jar" need not compare. When I discussed this
solution on IRC with Matt, he suggested that it may be better to
address this problem by changing how the dependency resolution
works for SNAPSHOT versions instead of copying the downloaded
version of artifact under a different name. In other words,
changed the dependency resolution such a dependency on 1.0-SNAPSHOT
is resolved to 1.0-SNAPSHOT or any released version of 1.0
available in the server's repository. It may be alright if just
"SNAPSHOT" is specified as dependency (which is as good as omitting
the version in dependency, or is it not?) as opposed to " 1.0-
SNAPSHOT". I don't think this will address the situation in (3).
Any suggestions on how (1) and (3) from above could be handled?
--vamsi
