Re: passing the deployed artifact URL to another system

2013-10-22 Thread 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 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=groupa=artif
actv=1.2.3r=repo_namee=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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: passing the deployed artifact URL to another system

2013-10-22 Thread Anders Hammar
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.dow...@gamesys.co.ukwrote:

 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=groupa=artif
 actv=1.2.3r=repo_namee=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, 

Re: passing the deployed artifact URL to another system

2013-10-22 Thread Russell Gold
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.dow...@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=groupa=artif
 actv=1.2.3r=repo_namee=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-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@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/!









Re: passing the deployed artifact URL to another system

2013-10-22 Thread Adam Downer
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 r...@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.dow...@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=groupa=art
if
 actv=1.2.3r=repo_namee=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-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: passing the deployed artifact URL to another system

2013-10-22 Thread Russell Gold
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.dow...@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 r...@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.dow...@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=groupa=art
 if
 actv=1.2.3r=repo_namee=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-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@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/!
 
 
 
 
 
 
 
 
 
 

passing the deployed artifact URL to another system

2013-10-21 Thread Adam Downer
Hi users,

I was wondering if there was a simple way to achieve the following. I have 
looked at the deploy plugin project pages, searched the mailing list and 
interwebs and I can't find examples of what I am trying to do or a possible 
method for me to achieve it.

I use maven to upload software to a nexus repository, no fancy tricks just jars 
and wars put into snapshot and release repositories.
I have written a small app which collates data about where artifacts have been 
deployed and what tests have been run against them.

My problem is this. I want to store the full nexus url of artifacts in my other 
app, to use as the main reference for data about them. I started writing a 
maven plugin to achieve this (passing the URL in an HTML post as data) but I 
can't find a way to get the deploy URL which is used during the deploy phase of 
the maven build.

I thought about constructing the url myself as the pattern is formulaic, but it 
involves timestamps, which if I generate again will be different to the real 
ones.

If anyone knows a way to achieve this or can share examples of a way it has 
been done. I would be most appreciative.

Regards

Adam D


Re: passing the deployed artifact URL to another system

2013-10-21 Thread Stephen Connolly
These are not the droids you are looking for...

Also, this is not the problem you want to solve... Nexus Pro has this nice
feature called staging whereby the URL you deploy to is not the same URL
that people download from. I know Artifactory has similar features.

The final nail in the coffin is that very often the deployment repository
is not configured as the download repository, as you deploy into an
internal repository but download from a group proxying repository (so that
you get fast builds by only asking 1 repository)

For the 99% the deploy URL is not the same as the download URL, so the best
you can do is query the attached artifact to determine the timestamp that
was used (for -SNAPSHOT deployment) and then construct the URL based off
the configured download URL that you expect to be downstream from where you
made your deployment


On 21 October 2013 11:00, Adam Downer adam.dow...@gamesys.co.uk wrote:

 Hi users,

 I was wondering if there was a simple way to achieve the following. I have
 looked at the deploy plugin project pages, searched the mailing list and
 interwebs and I can't find examples of what I am trying to do or a possible
 method for me to achieve it.

 I use maven to upload software to a nexus repository, no fancy tricks just
 jars and wars put into snapshot and release repositories.
 I have written a small app which collates data about where artifacts have
 been deployed and what tests have been run against them.

 My problem is this. I want to store the full nexus url of artifacts in my
 other app, to use as the main reference for data about them. I started
 writing a maven plugin to achieve this (passing the URL in an HTML post as
 data) but I can't find a way to get the deploy URL which is used during the
 deploy phase of the maven build.

 I thought about constructing the url myself as the pattern is formulaic,
 but it involves timestamps, which if I generate again will be different to
 the real ones.

 If anyone knows a way to achieve this or can share examples of a way it
 has been done. I would be most appreciative.

 Regards

 Adam D



Re: passing the deployed artifact URL to another system

2013-10-21 Thread Adam Downer
Thanks for your reply Stephen,

So, in my case at least, things are pretty simple

- No nexus pro. So no staging or other middle man type repos.
- No repository grouping. Releases is releases and snapshots is snapshots
(we have restrictions on who can access what and setting up groups made
this harder to manage effectively.

My builds upload to
http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
n/artifact.jar

Then production deployment will reference
http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
n/artifact.jar to get it on the environment.

I agree that people with more complicated setups (involving proxies,
staging repos, groups and non-nexus) will not find this so useful but I
still find it hard to believe that no one else has wanted to pass a
download url of an artifact from one build to another, maybe as a
parameter in a deployment script for instance.

The build process outputs the full URL to the console during the build.

[INFO] [deploy:deploy {execution: default-deploy}]
[INFO] Retrieving previous build number from deploy-snapshots
Uploading: 
http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
n/artifact.jar
4/7757K

...

So the URL is constructed somewhere in the maven execution to be used by
the deploy phase. Even if you can only point me to the maven deploy code
which does the construct, that would be helpful.


On 21/10/2013 13:30, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

These are not the droids you are looking for...

Also, this is not the problem you want to solve... Nexus Pro has this nice
feature called staging whereby the URL you deploy to is not the same URL
that people download from. I know Artifactory has similar features.

The final nail in the coffin is that very often the deployment repository
is not configured as the download repository, as you deploy into an
internal repository but download from a group proxying repository (so that
you get fast builds by only asking 1 repository)

For the 99% the deploy URL is not the same as the download URL, so the
best
you can do is query the attached artifact to determine the timestamp that
was used (for -SNAPSHOT deployment) and then construct the URL based off
the configured download URL that you expect to be downstream from where
you
made your deployment


On 21 October 2013 11:00, Adam Downer adam.dow...@gamesys.co.uk wrote:

 Hi users,

 I was wondering if there was a simple way to achieve the following. I
have
 looked at the deploy plugin project pages, searched the mailing list and
 interwebs and I can't find examples of what I am trying to do or a
possible
 method for me to achieve it.

 I use maven to upload software to a nexus repository, no fancy tricks
just
 jars and wars put into snapshot and release repositories.
 I have written a small app which collates data about where artifacts
have
 been deployed and what tests have been run against them.

 My problem is this. I want to store the full nexus url of artifacts in
my
 other app, to use as the main reference for data about them. I started
 writing a maven plugin to achieve this (passing the URL in an HTML post
as
 data) but I can't find a way to get the deploy URL which is used during
the
 deploy phase of the maven build.

 I thought about constructing the url myself as the pattern is formulaic,
 but it involves timestamps, which if I generate again will be different
to
 the real ones.

 If anyone knows a way to achieve this or can share examples of a way it
 has been done. I would be most appreciative.

 Regards

 Adam D



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: passing the deployed artifact URL to another system

2013-10-21 Thread Stephen Connolly
On 21 October 2013 14:23, Adam Downer adam.dow...@gamesys.co.uk wrote:

 Thanks for your reply Stephen,

 So, in my case at least, things are pretty simple

 - No nexus pro. So no staging or other middle man type repos.
 - No repository grouping. Releases is releases and snapshots is snapshots
 (we have restrictions on who can access what and setting up groups made
 this harder to manage effectively.

 My builds upload to
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar

Then production deployment will reference
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar to get it on the environment.


You are using a sub-optimal repository manager setup then. you should be
running a proxy of central + your releases + your snapshots as a minimum
and forcing everyone to use mirrorOf*/mirrorOf to that proxy...


 I agree that people with more complicated setups (involving proxies,
 staging repos, groups and non-nexus) will not find this so useful but I
 still find it hard to believe that no one else has wanted to pass a
 download url of an artifact from one build to another, maybe as a
 parameter in a deployment script for instance.

 The build process outputs the full URL to the console during the build.

 [INFO] [deploy:deploy {execution: default-deploy}]
 [INFO] Retrieving previous build number from deploy-snapshots
 Uploading:
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar
 4/7757K

 ...

 So the URL is constructed somewhere in the maven execution to be used by
 the deploy phase. Even if you can only point me to the maven deploy code
 which does the construct, that would be helpful.


 On 21/10/2013 13:30, Stephen Connolly stephen.alan.conno...@gmail.com
 wrote:

 These are not the droids you are looking for...
 
 Also, this is not the problem you want to solve... Nexus Pro has this nice
 feature called staging whereby the URL you deploy to is not the same URL
 that people download from. I know Artifactory has similar features.
 
 The final nail in the coffin is that very often the deployment repository
 is not configured as the download repository, as you deploy into an
 internal repository but download from a group proxying repository (so that
 you get fast builds by only asking 1 repository)
 
 For the 99% the deploy URL is not the same as the download URL, so the
 best
 you can do is query the attached artifact to determine the timestamp that
 was used (for -SNAPSHOT deployment) and then construct the URL based off
 the configured download URL that you expect to be downstream from where
 you
 made your deployment
 
 
 On 21 October 2013 11:00, Adam Downer adam.dow...@gamesys.co.uk wrote:
 
  Hi users,
 
  I was wondering if there was a simple way to achieve the following. I
 have
  looked at the deploy plugin project pages, searched the mailing list and
  interwebs and I can't find examples of what I am trying to do or a
 possible
  method for me to achieve it.
 
  I use maven to upload software to a nexus repository, no fancy tricks
 just
  jars and wars put into snapshot and release repositories.
  I have written a small app which collates data about where artifacts
 have
  been deployed and what tests have been run against them.
 
  My problem is this. I want to store the full nexus url of artifacts in
 my
  other app, to use as the main reference for data about them. I started
  writing a maven plugin to achieve this (passing the URL in an HTML post
 as
  data) but I can't find a way to get the deploy URL which is used during
 the
  deploy phase of the maven build.
 
  I thought about constructing the url myself as the pattern is formulaic,
  but it involves timestamps, which if I generate again will be different
 to
  the real ones.
 
  If anyone knows a way to achieve this or can share examples of a way it
  has been done. I would be most appreciative.
 
  Regards
 
  Adam D
 


 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@maven.apache.org




Re: passing the deployed artifact URL to another system

2013-10-21 Thread Adam Downer
I have continued to dig into the code in order to try and find a potential 
answer wo my question.

The mvane deploy plugin code
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-pluginhttps://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/src/main/java/org/apache/maven/plugin/deploy/DeployMojo.java

Probably contains the info I am looking for, or at least the method by which to 
consistently generate the info. I have also come across the shade plugin. Which 
seems to override the default behaviour of other plugins for its own purposes. 
I am thinking that maybe my maven plugin could override a portion of the 
standard deploy plugin in order to expose the information I require. Or maybe I 
am talking about two plugins now, an extension to 'deploy' to expose the 
required info in a ${project.finalRepoUploadURL} way and a second plugin to 
take that info and send it to my apps rest endpoint.

Thanks in advance.

Adam D

From: Adam Downer adam.dow...@gamesys.co.ukmailto:adam.dow...@gamesys.co.uk
Date: Monday, 21 October 2013 11:00
To: users@maven.apache.orgmailto:users@maven.apache.org 
users@maven.apache.orgmailto:users@maven.apache.org
Subject: passing the deployed artifact URL to another system

Hi users,

I was wondering if there was a simple way to achieve the following. I have 
looked at the deploy plugin project pages, searched the mailing list and 
interwebs and I can't find examples of what I am trying to do or a possible 
method for me to achieve it.

I use maven to upload software to a nexus repository, no fancy tricks just jars 
and wars put into snapshot and release repositories.
I have written a small app which collates data about where artifacts have been 
deployed and what tests have been run against them.

My problem is this. I want to store the full nexus url of artifacts in my other 
app, to use as the main reference for data about them. I started writing a 
maven plugin to achieve this (passing the URL in an HTML post as data) but I 
can't find a way to get the deploy URL which is used during the deploy phase of 
the maven build.

I thought about constructing the url myself as the pattern is formulaic, but it 
involves timestamps, which if I generate again will be different to the real 
ones.

If anyone knows a way to achieve this or can share examples of a way it has 
been done. I would be most appreciative.

Regards

Adam D


Re: passing the deployed artifact URL to another system

2013-10-21 Thread Russell Gold
There is a free version of nexus available; it is quite easy to configure. Why 
do you want to avoid the tools with which maven works best? A repository 
manager of some kind is a basic assumption of much of the way maven users work. 
It seems as though you are going out of your way to make it hard for yourself.

On Oct 21, 2013, at 9:23 AM, Adam Downer adam.dow...@gamesys.co.uk wrote:

 Thanks for your reply Stephen,
 
 So, in my case at least, things are pretty simple
 
 - No nexus pro. So no staging or other middle man type repos.
 - No repository grouping. Releases is releases and snapshots is snapshots
 (we have restrictions on who can access what and setting up groups made
 this harder to manage effectively.
 
 My builds upload to
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar
 
 Then production deployment will reference
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar to get it on the environment.
 
 I agree that people with more complicated setups (involving proxies,
 staging repos, groups and non-nexus) will not find this so useful but I
 still find it hard to believe that no one else has wanted to pass a
 download url of an artifact from one build to another, maybe as a
 parameter in a deployment script for instance.
 
 The build process outputs the full URL to the console during the build.
 
 [INFO] [deploy:deploy {execution: default-deploy}]
 [INFO] Retrieving previous build number from deploy-snapshots
 Uploading: 
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
 n/artifact.jar
 4/7757K
 
 ...
 
 So the URL is constructed somewhere in the maven execution to be used by
 the deploy phase. Even if you can only point me to the maven deploy code
 which does the construct, that would be helpful.
 
 
 On 21/10/2013 13:30, Stephen Connolly stephen.alan.conno...@gmail.com
 wrote:
 
 These are not the droids you are looking for...
 
 Also, this is not the problem you want to solve... Nexus Pro has this nice
 feature called staging whereby the URL you deploy to is not the same URL
 that people download from. I know Artifactory has similar features.
 
 The final nail in the coffin is that very often the deployment repository
 is not configured as the download repository, as you deploy into an
 internal repository but download from a group proxying repository (so that
 you get fast builds by only asking 1 repository)
 
 For the 99% the deploy URL is not the same as the download URL, so the
 best
 you can do is query the attached artifact to determine the timestamp that
 was used (for -SNAPSHOT deployment) and then construct the URL based off
 the configured download URL that you expect to be downstream from where
 you
 made your deployment
 
 
 On 21 October 2013 11:00, Adam Downer adam.dow...@gamesys.co.uk wrote:
 
 Hi users,
 
 I was wondering if there was a simple way to achieve the following. I
 have
 looked at the deploy plugin project pages, searched the mailing list and
 interwebs and I can't find examples of what I am trying to do or a
 possible
 method for me to achieve it.
 
 I use maven to upload software to a nexus repository, no fancy tricks
 just
 jars and wars put into snapshot and release repositories.
 I have written a small app which collates data about where artifacts
 have
 been deployed and what tests have been run against them.
 
 My problem is this. I want to store the full nexus url of artifacts in
 my
 other app, to use as the main reference for data about them. I started
 writing a maven plugin to achieve this (passing the URL in an HTML post
 as
 data) but I can't find a way to get the deploy URL which is used during
 the
 deploy phase of the maven build.
 
 I thought about constructing the url myself as the pattern is formulaic,
 but it involves timestamps, which if I generate again will be different
 to
 the real ones.
 
 If anyone knows a way to achieve this or can share examples of a way it
 has been done. I would be most appreciative.
 
 Regards
 
 Adam D
 
 
 
 -
 To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
 For additional commands, e-mail: users-h...@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/!









Re: passing the deployed artifact URL to another system

2013-10-21 Thread Curtis Rueden
Hi Russell, Adam  everyone,

Russell wrote:
 There is a free version of nexus available

He already said he is using Nexus. And anyway, use Nexus does not address
his actual question.

Adam wrote:
 I want to store the full nexus url of artifacts in my other app, to
 use as the main reference for data about them.

Personally I would like a little more information before passing judgment
about what you are trying to achieve.

The thing about distributed repositories across the Internet is: there is
no one central index of all of them. (http://mvnrepository.com/ tries but
it is only a few of them. It can't possibly know about all of them,
especially non-public ones.)

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.

Regards,
Curtis


On Mon, Oct 21, 2013 at 11:58 AM, Russell Gold r...@gold-family.us wrote:

 There is a free version of nexus available; it is quite easy to configure.
 Why do you want to avoid the tools with which maven works best? A
 repository manager of some kind is a basic assumption of much of the way
 maven users work. It seems as though you are going out of your way to make
 it hard for yourself.

 On Oct 21, 2013, at 9:23 AM, Adam Downer adam.dow...@gamesys.co.uk
 wrote:

  Thanks for your reply Stephen,
 
  So, in my case at least, things are pretty simple
 
  - No nexus pro. So no staging or other middle man type repos.
  - No repository grouping. Releases is releases and snapshots is snapshots
  (we have restrictions on who can access what and setting up groups made
  this harder to manage effectively.
 
  My builds upload to
 
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
  n/artifact.jar
 
  Then production deployment will reference
 
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
  n/artifact.jar to get it on the environment.
 
  I agree that people with more complicated setups (involving proxies,
  staging repos, groups and non-nexus) will not find this so useful but I
  still find it hard to believe that no one else has wanted to pass a
  download url of an artifact from one build to another, maybe as a
  parameter in a deployment script for instance.
 
  The build process outputs the full URL to the console during the build.
 
  [INFO] [deploy:deploy {execution: default-deploy}]
  [INFO] Retrieving previous build number from deploy-snapshots
  Uploading:
 
 http://nexus.mycompany/content/repositories/repo_name/group/artifact/versio
  n/artifact.jar
  4/7757K
 
  ...
 
  So the URL is constructed somewhere in the maven execution to be used by
  the deploy phase. Even if you can only point me to the maven deploy code
  which does the construct, that would be helpful.
 
 
  On 21/10/2013 13:30, Stephen Connolly stephen.alan.conno...@gmail.com
 
  wrote:
 
  These are not the droids you are looking for...
 
  Also, this is not the problem you want to solve... Nexus Pro has this
 nice
  feature called staging whereby the URL you deploy to is not the same URL
  that people download from. I know Artifactory has similar features.
 
  The final nail in the coffin is that very often the deployment
 repository
  is not configured as the download repository, as you deploy into an
  internal repository but download from a group proxying repository (so
 that
  you get fast builds by only asking 1 repository)
 
  For the 99% the deploy URL is not the same as the download URL, so the
  best
  you can do is query the attached artifact to determine the timestamp
 that
  was used (for -SNAPSHOT deployment) and then construct the URL based off
  the configured download URL that you expect to be downstream from where
  you
  made your deployment
 
 
  On 21 October 2013 11:00, Adam Downer adam.dow...@gamesys.co.uk
 wrote:
 
  Hi users,
 
  I was wondering if there was a simple way to achieve the following. I
  have
  looked at the deploy plugin project pages, searched the mailing list
 and
  interwebs and I can't find examples of what I am trying to do or a
  possible
  method for me to achieve it.
 
  I use maven to upload software to a nexus repository, no fancy tricks
  just
  jars and wars put into snapshot and release repositories.
  I have written a small app which collates data about where artifacts
  have
  been deployed and what tests have been run against them.
 
  My problem is this. I want to store the full nexus url of artifacts in
  my
  other