You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Olivier Dehon <od...@gmail.com> on 2007/05/26 20:56:46 UTC
How to resolve dependency from remote repositories only?
Hi,
I am trying to to use ArtifactResolver.resolve method on my project
artifact, which can be a snapshot version,
but I would like to get to the latest "deployed" version of the
artifact, even if the "installed" version is more recent.
The reason behind this is I need to calculate the HTTP URL of the latest
deployed snapshot version, which would be
something like
http://repo.my-repo-host.com/archiva/repo-snapshots/com/foo/bar/project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
I can get the initial part of the URL through
deploymentRepository.getUrl(), and the path to the artifact through
deploymentRepository.pathOf( artifact )
The problem is that if the artifact resolves to a version installed in
the local repository, deploymentRepository.pathOf( artifact ) yields:
com/foo/bar/project/1.0-SNAPSHOT/project-1.0-SNAPSHOT.jar, instead of
the expected
com/foo/bar/project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
Thanks for sharing your experience with this.
-Olivier
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve dependency from remote repositories only?
Posted by Olivier Dehon <od...@gmail.com>.
Thanks for your answer. I'll try that.
I am a bit puzzled though that the pathOf method on the
deploymentRepository instance yields a result that is not an existing path.
Another thing I tried is to link my Mojo to the deploy phase through:
@goal olivier
@execution phase=deploy
but I came across what I think might be a bug in the deploy plugin
(version 2.2.1, under maven 2.0.5):
If I run "mvn deploy", everything runs fine and my JAR is deployed in
Archiva, thanks to the <distributionManagement> section in my POM.
Now, if I run "mvn olivier:olivier", a new lifecycle kicks off with
compilation, install, and deploy, but the deploy fails claiming that it
can't find
the distributionManagement data.
Maybe the distributionManagement data is not copied into the cloned
project for the forked lifecycle?
-Olivier
John Casey wrote:
> You could use the local repository instance to construct a
> java.io.File pointing to any locally installed version of the
> artifact, then delete them...that should force maven to re-resolve
> them. If you don't want to delete them, you could always rename them.
>
> That's probably the simplest way I can think to do it.
>
> -john
>
>
> On May 26, 2007, at 2:56 PM, Olivier Dehon wrote:
>
>> Hi,
>>
>> I am trying to to use ArtifactResolver.resolve method on my project
>> artifact, which can be a snapshot version,
>> but I would like to get to the latest "deployed" version of the
>> artifact, even if the "installed" version is more recent.
>>
>> The reason behind this is I need to calculate the HTTP URL of the
>> latest deployed snapshot version, which would be
>> something like
>> http://repo.my-repo-host.com/archiva/repo-snapshots/com/foo/bar/project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
>>
>>
>> I can get the initial part of the URL through
>> deploymentRepository.getUrl(), and the path to the artifact through
>> deploymentRepository.pathOf( artifact )
>>
>> The problem is that if the artifact resolves to a version installed
>> in the local repository, deploymentRepository.pathOf( artifact ) yields:
>> com/foo/bar/project/1.0-SNAPSHOT/project-1.0-SNAPSHOT.jar, instead of
>> the expected
>> com/foo/bar/project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
>>
>> Thanks for sharing your experience with this.
>>
>> -Olivier
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
> ---
> John Casey
> Committer and PMC Member, Apache Maven
> mail: jdcasey at commonjava dot org
> blog: http://www.ejlife.net/blogs/john
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: How to resolve dependency from remote repositories only?
Posted by John Casey <jd...@commonjava.org>.
You could use the local repository instance to construct a
java.io.File pointing to any locally installed version of the
artifact, then delete them...that should force maven to re-resolve
them. If you don't want to delete them, you could always rename them.
That's probably the simplest way I can think to do it.
-john
On May 26, 2007, at 2:56 PM, Olivier Dehon wrote:
> Hi,
>
> I am trying to to use ArtifactResolver.resolve method on my project
> artifact, which can be a snapshot version,
> but I would like to get to the latest "deployed" version of the
> artifact, even if the "installed" version is more recent.
>
> The reason behind this is I need to calculate the HTTP URL of the
> latest deployed snapshot version, which would be
> something like
> http://repo.my-repo-host.com/archiva/repo-snapshots/com/foo/bar/
> project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
>
> I can get the initial part of the URL through
> deploymentRepository.getUrl(), and the path to the artifact through
> deploymentRepository.pathOf( artifact )
>
> The problem is that if the artifact resolves to a version installed
> in the local repository, deploymentRepository.pathOf( artifact )
> yields:
> com/foo/bar/project/1.0-SNAPSHOT/project-1.0-SNAPSHOT.jar, instead
> of the expected
> com/foo/bar/project/1.0-SNAPSHOT/project-1.0-20070526.145203-5.jar
>
> Thanks for sharing your experience with this.
>
> -Olivier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john