geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anita Kulshreshtha <a_kuls...@yahoo.com>
Subject Re: Dependency resolution for SNAPSHOT versions
Date Thu, 09 Aug 2007 15:34:46 GMT
    I have a serious issue with maven's snapshot handling. IMNSHO, I do
not like the fact that our .m2 repo is littered with timestamped
SNAPSHOTs. If my build is using SNAPSHOTs, all I want is the latest
version. For anything else I would specify a TS snapshot, which should
get downloaded in .../m.n-<TS>... directory instead of
.../m.n-SNAPSHOT/... If my build really wanted to know the ts for the
SNAPSHOT, I would read maven-metadata.xml. This would simplify the
programs (like GBean installer) that interact with .m2 repo as if it
was a simple directory. 
    But this is just a dream... 

Thanks
Anita

--- Paul McMahan <paulmcmahan@gmail.com> 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
> 
> 



       
____________________________________________________________________________________
Got a little couch potato? 
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz 

Mime
View raw message