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 <[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
>
>
____________________________________________________________________________________
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
