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=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-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 > ----------------- 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/>!
