geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul McMahan <>
Subject Re: Dependency resolution for SNAPSHOT versions
Date Thu, 09 Aug 2007 14:58:40 GMT
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,

is actually satisfied by a jar at :
<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:

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:

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,

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