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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to