geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vamsavardhana Reddy" <>
Subject Re: Dependency resolution for SNAPSHOT versions
Date Thu, 09 Aug 2007 15:06:05 GMT
Thanks for the detailed explanation Paul.


On 8/9/07, Paul McMahan <> wrote:
> 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

View raw message