maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Downer <>
Subject Re: passing the deployed artifact URL to another system
Date Tue, 22 Oct 2013 13:39:06 GMT
Hi Russ,
Can you specify individual timestamped snapshots in a GAV based request?

I will look into the nexus pro/plugin | Artifactory route, thanks.


Adam D

On 22/10/2013 13:13, "Russell Gold" <> wrote:

>HI Adam,
>I'd think this would be easier to handle using the artifacts' GAV
>coordinates directly rather than the remote URL. Those should be
>predictable and you'd probably use Maven to download them anyway. So why
>not use the coordinates as your key?
>- Russ
>On Oct 22, 2013, at 6:10 AM, Adam Downer <>
>> Hi Curtis,
>> A little bit more background information. I hope this illustrates better
>> what I am trying to achieve.
>> The tool I am writing is not another repository of actual software or
>> of the information already stored in nexus (SHA1's etc.) but a database
>> extra metadata about deployable artifacts that nexus doesn't already
>> using the absolute URL as a key. It is focused on deployments of my
>> companies own software. It will not be trying to store data on third
>> jars which, as you correctly point out, I can't hope to maintain an
>> for all that and with nexus running a proxy group for optimal access to
>> all the external repos the devs use, the resolved download location
>> be different in each case.
>>> If I understand correctly, you are trying to derive a remote repository
>>> path from a GAV. Is that correct? Firstly, I will second what Stephen
>>> pointed out: the deploy path (i.e., for upload) is not the same thing
>>> the resolution path (i.e., for downloading again later). I am guessing
>>> your
>>> application actually cares about where these artifacts (and their POMs)
>>> can
>>> be downloaded, rather than what path was actually used at deploy time.
>>> If so, is there something wrong with simply having a hardcoded list of
>>> repository base URLs, from which you can scan for the GAVs? That's
>>> much what Maven does with its <repositories> elements.
>> If by remote repository path you mean maven central or other externally
>> host location, no I am not trying to do that. This is only for my
>> hosted internal release repository which contains a finite set of known
>> projects. I don't really want to guess at the path based on GAV as I
>> have to make assumptions about the repo location which means hard coding
>> it which, in turn, means more maintenance should I change the nexus
>> service in some way. As I see it, the maven deploy has code takes all
>> into account when it is building the artifact. So I don't want to
>> the wheel, just take advantage of code that already does what I want,
>> doesn't expose it in a way I can currently use.
>> The tools database will contain the fully resolved nexus URL of an
>> artefact:
>> n/artifact.jar
>> Not an interpreted route to the artefact:
>> act&v=1.2.3&r=repo_name&e=jar
>> The absolute URL of the artefact is used by our deployment scripts to
>> download the artefact it wants to deploy. I am going to make our
>> deployment scripts query the new application to check for certain flags
>> (smoke tested, etc.) before allowing the deploy to proceed.
>> To that end I need to populate the database as new items get built. My
>> thought was to use maven to do this as (at build time) maven knows the
>> absolute URL of the artifact. Or at least it gives the impression it
>> as it displays it in the console during the deploy phase.
>>> [INFO] [deploy:deploy {execution: default-deploy}]
>>> [INFO] Retrieving previous build number from deploy-snapshots
>>> Uploading:
>>> o
>>> n/artifact.jar
>> If there is an alternative way to achieve this I am open to any
>> suggestions. For instance maybe I should write a script which runs from
>> the nexus box and fires off constructed URLs to a rest endpoint as the
>> file system changes. But this doesn't seem as elegant a solution as a
>> maven based one.
>> Regards
>> Adam D
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
>Author, Getting Started with Apache Maven
>Come read my webnovel, Take a Lemon <>,
>and listen to the Misfile radio play

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message