geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lin Sun <>
Subject Re: Dependency resolution for SNAPSHOT versions
Date Wed, 08 Aug 2007 20:29:30 GMT
Hi, I thought the is designed for this 
purpose (if it supports the jar module as well as the car module), but 
that may just be my wishful thinking. ;)


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