You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Vamsavardhana Reddy <c1...@gmail.com> on 2007/08/08 21:13:05 UTC
Dependency resolution for SNAPSHOT versions
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.0available 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
Re: Dependency resolution for SNAPSHOT versions
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
When I start installing a plug-in, I will expect that the plugin installer
will download only those dependencies that could not be resolved currently.
I guess the artifact_aliases.properties file will be used at this resolution
step. Once it is past that, it either downloads the dependency or fails
saying it can not download the dependency. In exmple (1), it is downloading
a different version of the depedency, still assumes it has downloaded the
required one, proceeds to download further dependencies and fails at
starting the plugin!!
--vamsi
On 8/9/07, Lin Sun <li...@gmail.com> wrote:
>
> Hi, I thought the artifact_aliases.properties 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. ;)
>
> Lin
>
> 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
>
>
Re: Dependency resolution for SNAPSHOT versions
Posted by Lin Sun <li...@gmail.com>.
Hi, I thought the artifact_aliases.properties 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. ;)
Lin
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
Re: Dependency resolution for SNAPSHOT versions
Posted by Vamsavardhana Reddy <c1...@gmail.com>.
Thanks for the detailed explanation Paul.
--vamsi
On 8/9/07, Paul McMahan <pa...@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
>
>
Re: Dependency resolution for SNAPSHOT versions
Posted by Anita Kulshreshtha <a_...@yahoo.com>.
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 <pa...@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
Re: Dependency resolution for SNAPSHOT versions
Posted by Paul McMahan <pa...@gmail.com>.
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