Thanks for the detailed explanation Paul. --vamsi
On 8/9/07, Paul McMahan <[EMAIL PROTECTED]> 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 > >
