Pure ivy.xml artifact resolution
Locked
 
|
|
|
|
|
|
|
|
|
|
|
Hi Yoav,
I've attached my repo configuration file.... there are 2 repo's of interest, orion-ivy-remote (for jars) and orion-ivy-ivyfiles (for descriptors) - i found i had to map the descriptor paths as a separate repo for them to be resolved when i asked for a 'pom' type in my local pom.xml. When I ask for an artifact which I know is an ivy.xml I use type 'pom' - this does a nice job of finding the ivy.xml and returning it as a .pom - still with the ivy.xml as content however. The guts of artifactory complains that it can't resolve any maven modules from it - this is to be expected of course. Some issues i have are: 1. i can only get the 'true' path to the ivy.xml (i.e. ..../ivy.xml) when in the afterRemoteDownload callback - the remoteRepoPath gives this to me fine. Anywhere else it is looking for a .pom which means using <i>def origContent = "${repoUrl}/${repoPath.path}".toURL().text</i> misses. I haven't tried hard to get around this yet but if i can it will resolve this problem for me. 2. I've tried the Repositories.getStringContent(repoPath) without success - result is always empty... I suspect this may be for the same reason as above. 3. My remote repos have 'Do not Store Artifacts Locally' checked. I do notice that if I do a Repositories.exist(ivyfilesRepoPath) i get an exception complaining that the repo is not local. There are a few things I want to try again however so no need to respond just yet - unless there is something obvious that I'm missing. I think my main issue is that I don't yet entirely understand all the details of artifactory and how the lifecycle of resolving artifacts works - is there a decent document somewhere that outlines that? Regards, Jon ----- Original Message ----- From: "Yoav Landman [via Artifactory]" <[hidden email]> To: "joncourt" <[hidden email]> Sent: Thursday, 16 February, 2012 11:13:07 AM Subject: Re: Pure ivy.xml artifact resolution Hi Jon, You should be able to use Repositories.getContent() or Repositories. getStringContent() and specify the repoPath of the remote repository (with or without "-cache" - both should work). Is that what you tried? Also, is your remote repo set to store artifacts locally? Which version of Artifactory are you trying this with? Yoav On Mon, Feb 13, 2012 at 3:57 AM, joncourt < [hidden email] > wrote: Thanks Yoav. Thanks for the help... I am progressing. My question now is: how do i get a handle on the original content in the afterRemoteDownload or altRemoteContent callbacks? *Where I'm at:* I'm in the afterRemoteDownload callback now.... I can write out a pom to another repository mapped as you say. My problem now is I can't seem to get a handle on the original content (i.e. the ivy.xml) to translate it. I've tried request.getInputStream() but it's null. I've also tried the getStringContent() method on the repositories object. I've also successfully used the altRemoteContent callback to change the content on the fly (and have it cached) and this works well - except again I can't get a handle on the original content (I've been testing the concept with a hardcoded pom xml string). Here I've tried the inputStream context var but as the doco says this is a 'new' instance - so is null by the time I reach it of course. It is nice that when i ask for a type 'pom' in my local pom file it get's automatically mapped to the Ivy descriptor in my ivy repo - nice bit of magic there. Hopefully I've just missed something. Regards, Jon Yoav Landman-2 wrote > > Hi Jon, > > You can write a plugin that tends to the afterRemoteDownload() callback > and > generates and saves the pom.xml in a local repo that uses the maven > layout. > Sounds like you already have a good foundation in place for supporting > this. > Then, as Eli suggested, you can have a virtual repo (using maven layout) > that wraps both your ivy remote repo cache and the local maven repo under > a > single URL. > When/if your ivy repo becomes irrelevant, you can move/copy all artifacts > to the local maven repo (this entails a cheap copy/move due Artifactory's > checksum based storage), and automatic layout translation will put the > artifacts in the right location, according to standard maven layout. > > The way users take advantage of plugins varies greatly to support many > custom use cases. We've started putting together a small > repo< https://github.com/JFrogDev/artifactory-user-plugins>with > sample > plugins, and it'd be great to have a plugin such as this one as > a contribution. Let us know if you need any help with this (you can also > contact support@). > > Thanks, > Yoav > > On Wed, Feb 8, 2012 at 2:26 AM, joncourt <jon.court@> wrote: > >> Hi Eli, >> >> Thanks for your reply. >> >> In summary my question now is - is it possible to build a plugin to >> artifactory to generate a pom.xml on the way from the remote ivy repo to >> the >> local maven style repo? If so do you know of a good reference I can use >> to >> achieve it? >> >> *Why?* >> I have a proxy repo setup in Ivy with remote set to our custom ivy layout >> and local set to the default maven layout - our maven projects will use >> this >> proxy repo as we roll off our ant-ivy build onto a maven build. I like >> ant/ivy and maven; maven makes considerably more sense here however - >> hence >> the move. >> >> Reading between the lines of your reply it's clear I've missed a key bit >> of >> understanding with respect to Artifactory. I find myself assuming that >> Artifactory is 'on-the-fly' translating the ivy.xml artifact to a pom >> syntax >> that our maven builds can read on the way from our Ivy rep through the >> Artifactory proxy. When you think about it this would be rather difficult >> to >> generically support - especially since our ivy files don't use the >> standard >> maven configurations (master, compile, runtime, ....etc). >> >> What I */could/* do, as you say, is create a maven plugin that can read >> the >> ivy.xml and translate it to it's own domain language. I can envisage a >> bit >> of ivy api usage, perhaps a call to the makepom functionality that Ivy >> has. >> I have used the Ant task which uses this feature quite extensively in the >> past and found that if I added a bit of XSL to powerup the output pom (in >> order to support some of the conflict manager and exclusion syntax that >> ivy >> supports) it worked very well. The limitations of ivy's makepom >> functionality wouldn't affect us here I think as we make little or no >> usage >> of the conflict resolution features of ivy. >> >> What I would /*like*/ to do is create an Artifactory plugin that >> generates >> a >> pom from the Ivy.xml as it caches the artifacts into the maven layout >> local >> repo from the remote repo. This pom could then be used by the maven >> projects >> to resolve transient dependencies etc... this way our legacy code can be >> migrated as we use it, converted builds can go straight into a maven repo >> and legacy ant/ivy builds can continue to go into the ivy repo without >> change. When we're on maven completely the ivy repo will age gracefully >> until we need it no more and turn it off. Of course ivy can read the >> maven >> repo so legacy projects can easily depend on maven built projects. A >> maven >> plugin will achieve all this too i guess - but it doesn't feel as tidy to >> me. >> >> Is this reasonable - or have I missed something that would block it? >> >> NB: I'd love to give Gradle a go, ain't gonna happen soon though :). >> Probably doesn't quite make sense here either - some of the reasons for >> the >> maven switch are not yet supported by gradle. >> >> Regards, >> Jon >> >> >> Eli Givoni wrote >> > >> > Hi Jon, >> > >> > How are you planing to make maven resolve dependencies from ivy.xml? It >> > sounds like you are ready to use Gradle :) >> > >> > Once you find a way to process the ivy.xml inside your maven job you >> can >> > use a single Virtual repository layout conversion to handle Ivy and >> Maven >> > requests, you can read all about Repositories layouts >> > here< >> http://wiki.jfrog.org/confluence/display/RTF/Repository+Layouts> ;. >> > Basically you set up one Virtual repository with maven-2-default layout >> > set. The ivy.xml should be deployed on an Ivy layout repository. When >> an >> > ivy layout request will hit the virtual repository it will know how to >> > translate the path for example maven/way/path to ivy.way/path and >> resolve >> > the ivy.xml and ivy dependencies. >> > >> > HTH, >> > >> > Eli >> > >> > >> > On Thu, Feb 2, 2012 at 4:48 AM, joncourt <jon.court@> wrote: >> > >> >> Hi, >> >> >> >> Is it possible to utilise a pure ivy.xml artifact as a way of >> coalescing >> >> a >> >> bunch of dependencies and expose it to maven based projects? >> >> >> >> We have a bunch of these types of artifacts which in our ivy repo >> which >> >> don't actually have any jars in them but are used to specify a load of >> >> transient dependencies. I can't resolve them at the moment using any >> of >> >> the >> >> combinations of a dependency in maven (i.e. combo's of classifier and >> >> type). >> >> You can do this with pure maven or pure ivy - doesn't seem to >> translate >> >> however. >> >> >> >> Regards, >> >> Jon >> >> >> >> -- >> >> View this message in context: >> >> >> http://forums.jfrog.org/Pure-ivy-xml-artifact-resolution-tp7245579p7245579.html >> >> Sent from the Artifactory - Users mailing list archive at Nabble.com. >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> Keep Your Developer Skills Current with LearnDevNow! >> >> The most comprehensive online learning library for Microsoft >> developers >> >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >> MVC3, >> >> Metro Style Apps, more. Free future releases when you subscribe now! >> >> http://p.sf.net/sfu/learndevnow-d2d >> >> _______________________________________________ >> >> Artifactory-users mailing list >> >> Artifactory-users@.sourceforge >> >> https://lists.sourceforge.net/lists/listinfo/artifactory-users >> >> >> > >> > >> ------------------------------------------------------------------------------ >> > Keep Your Developer Skills Current with LearnDevNow! >> > The most comprehensive online learning library for Microsoft developers >> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >> MVC3, >> > Metro Style Apps, more. Free future releases when you subscribe now! >> > http://p.sf.net/sfu/learndevnow-d2d >> > _______________________________________________ >> > Artifactory-users mailing list >> > Artifactory-users@.sourceforge >> > https://lists.sourceforge.net/lists/listinfo/artifactory-users >> > >> >> >> -- >> View this message in context: >> http://artifactory-users.108859.n3.nabble.com/Pure-ivy-xml-artifact-resolution-tp3709002p3724446.html >> Sent from the Artifactory - Users mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Artifactory-users mailing list >> Artifactory-users@.sourceforge >> https://lists.sourceforge.net/lists/listinfo/artifactory-users >> > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Artifactory-users mailing list > Artifactory-users@.sourceforge > https://lists.sourceforge.net/lists/listinfo/artifactory-users > -- View this message in context: http://artifactory-users.108859.n3.nabble.com/Pure-ivy-xml-artifact-resolution-tp3709002p3738995.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Artifactory-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/artifactory-users ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Artifactory-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/artifactory-users If you reply to this email, your message will be added to the discussion below: http://forums.jfrog.org/Pure-ivy-xml-artifact-resolution-tp7245579p7289199.html To unsubscribe from Pure ivy.xml artifact resolution, click here . NAML |
artifactory.config.latest.xml (81K) |
|
|
|
In reply to this post by joncourt
Hi Jon,
My initial suggestion was to: (1) Download Ivy descriptors using Ivy (not Maven) to a remote repo, such as orion-ivy-ivyfiles (not sure why you needed to split the remote repos, BTW)
(2) Using a plugin, transform an Ivy file in afterRemoteDownload() to a POM and redeploy it to a maven local repo from which your Maven builds resolve. Transformation can only be done if orion-ivy-ivyfiles stores the Ivy files (uncheck 'Do not Store Artifacts Locally'). Then you can get to the files using the Repositories object.
It is possible, though a bit intrusive, to make the transformation on the fly, without keeping the requested Ivy files by using the altRemoteContent and altRemotePath handles. It still makes sense to store artifacts locally to host the resolved POM and avoid repeating the transformation.
As a general hint, since you know the path you are after, you can craft it the way you want and don't need to stick with the value of repoPath - so, if you the get the POM and need the Ivy file, simply create the path you are after as a new groovy var.
Hope that helps, Yoav On Thu, Feb 16, 2012 at 1:18 AM, joncourt <[hidden email]> wrote: Hi Yoav,
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Artifactory-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/artifactory-users |
|
|
|
|
Loading...
| Powered by Nabble | See how NAML generates this page |
