maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Gold <r...@gold-family.us>
Subject Re: passing the deployed artifact URL to another system
Date Tue, 22 Oct 2013 14:35:36 GMT
individual timestamped snapshots? No. 

I clearly do not understand your goals, here. In general, you cannot get at older snapshots
via maven, so I don't understand why keeping information on it is useful.

Regards,
Russ

On Oct 22, 2013, at 9:39 AM, Adam Downer <Adam.Downer@Gamesys.co.uk> wrote:

> Hi Russ,
> Can you specify individual timestamped snapshots in a GAV based request?
> 
> Anders,
> I will look into the nexus pro/plugin | Artifactory route, thanks.
> 
> Regards
> 
> Adam D
> 
> 
> On 22/10/2013 13:13, "Russell Gold" <russ@gold-family.us> 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 <Adam.Downer@Gamesys.co.uk>
>> wrote:
>> 
>>> 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
>>> any
>>> of the information already stored in nexus (SHA1's etc.) but a database
>>> of
>>> extra metadata about deployable artifacts that nexus doesn't already
>>> store
>>> 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
>>> party
>>> jars which, as you correctly point out, I can't hope to maintain an
>>> index
>>> 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
>>> could
>>> 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
>>>> as
>>>> 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
>>>> pretty
>>>> 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
>>> locally
>>> 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
>>> will
>>> 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
>>> this
>>> into account when it is building the artifact. So I don't want to
>>> reinvent
>>> the wheel, just take advantage of code that already does what I want,
>>> but
>>> doesn't expose it in a way I can currently use.
>>> 
>>> The tools database will contain the fully resolved nexus URL of an
>>> artefact:
>>> 
>>> http://nexus.mycompany/content/repositories/repo_name/group/artifact/vers
>>> io
>>> n/artifact.jar
>>> 
>>> Not an interpreted route to the artefact:
>>> 
>>> http://nexus.mycompany/service/local/artifact/maven/resolve?g=group&a=art
>>> if
>>> 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
>>> does
>>> 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:
>>>> 
>>>> 
>>>> http://nexus.mycompany/content/repositories/repo_name/group/artifact/ver
>>>> si
>>>> 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: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>> 
>> 
>> -----------------
>> Author, Getting Started with Apache Maven
>> <http://www.packtpub.com/getting-started-with-apache-maven/video>
>> 
>> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
>> and listen to the Misfile radio play
>> <http://www.fuzzyfacetheater.com/misfile/>!
>> 
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
> 

-----------------
Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video>

Come read my webnovel, Take a Lemon <http://www.takealemon.com>, 
and listen to the Misfile radio play <http://www.fuzzyfacetheater.com/misfile/>!








Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message