maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anders Hammar <and...@hammar.net>
Subject Re: passing the deployed artifact URL to another system
Date Tue, 22 Oct 2013 10:53:13 GMT
I would implement this by managing the extra metadata in Nexus. Nexus Pro
has support for this and if you think it is easier and/or cheaper to
implement this support yourself you can do so through a Nexus plugin.
Just so we don't start a repo manager war here, Artifactory also has the
same support (I believe it also requires the commercial version, but I
could be wrong).

So I would be tagging the artifacts in Nexus with QA status etc. And then
have the deploy tool query this before pushing to production. The deploy
tool could then even add even more metadata in Nexus stating when it was
put into production.
The deploy tool would need to know about the URL to a repo group in Nexus
where it can find artifacts to deploy. It should NOT have to look in
multiple repos, but just one single repo (group). The content of the repo
group is managed in Nexus. When retrieving an artifact from Nexus, the tool
should have to use the fully resolved URL. That's just a pain to create
when you can use the much simpler REST services available in Nexus where
you provide the GAV coordinates for example.

Any further questions on Nexus and Nexus plugin development should be
addressed to the Nexus users list, not this list. Use some Internet search
engine to find info about that list.

/Anders


On Tue, Oct 22, 2013 at 12:10 PM, 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/versio
> n/artifact.jar
>
> Not an interpreted route to the artefact:
> http://nexus.mycompany/service/local/artifact/maven/resolve?g=group&a=artif
> 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/versi
> >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
>
>

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