Hi, Just out of curiosity, what is the order of your resolvers?
Mine is: local shared releases everything else -=david=- On 27 September 2010 16:45, Steve Miller <thatguy1...@gmail.com> wrote: > Sounds like you're on the right track for sure. > > As far as resolvers go, I have been using returnFirst=true. If I > publish something in my local repo, I always want ivy to use that. > When I'm done developing locally, I clear out my local repo so that > the shared repo is used. It doesn't hurt to do it the way your doing > it, assuming ivy can figure out the latest, but it may decrease > performance of the resolve task. > > Steve > > On Mon, Sep 27, 2010 at 11:39 AM, David Harrigan <dharri...@gmail.com> wrote: >> Hi All, >> >> Thanks to everyone who replied :-) >> >> (Yes Steve, it is as you say - after a bit of experimentation I >> understand it now) >> >> I have something working now, this is my setup (btw, using artifactory >> which rocks): >> >> Module A: >> module.version=0.1.0-SNAPSHOT >> >> When I build my jar, a fubar.jar is created in my dist directory. When >> I publish to >> artifactory (libs-snaphots-local), it goes in as fubar-0.1.0-SNAPSHOT.jar. >> >> Module B: >> In my ivy.xml, I have declared a dependency on fubar as >> rev="latest.integration" >> which pulls down from artifactory version 0.1.0-SNAPSHOT (or whatever it is). >> >> Whenever I do a new build of Module A, I keep the version to be >> 0.1.0-SNAPSHOT, >> but the great thing is when I publish it, the date has changed so when I ask >> Module B to do a resolve for me, it pulls down the latest from artifactory. >> >> If I now do this: >> >> ant -Dmodule.version=0.1.0 ivy.publish.release >> >> Module A goes into the libs-releases-local of artifactory. >> >> Now in my Module B ivy.xml, I change the rev from latest.integration to >> 0.1.0 and when ivy does a resolve in Module B it pulls down the release >> version. >> >> Neato. >> >> I like the fact that I can control the version numbers myself which is good. >> >> I think I understand it now, would I be on the right track? >> >> My last question I have now is local artifacts verses remote artifacts. >> >> Say I am working on Module A. Doing some code changes. I publish >> locally my snapshot (say 0.2.0-SNAPSHOT). In my Module B, I have >> changed the dependency on Module A revision from 0.1.0 now to >> latest.integration. >> >> I remove the value "returnFirst" from my chain and indeed when I do >> a resolve on Module B, ivy installs Module A 0.2.0-SNAPSHOT into >> my Module B libs directory. >> >> My question is this: >> >> Is it correct to leave of returnFirst so that it forces Ivy to examine all >> of the configured resolvers to correctly compare comparisons? >> >> I feel that everything seems to be working well, just looking for some >> assurance that what I've done is accepted good practice and I'm not >> leaving anything out. >> >> Thank you again one and all, it's been a very helpful few hours :-) >> >> -=david=- >> >> >> On 27 September 2010 14:33, Steve Miller <thatguy1...@gmail.com> wrote: >>> Actually, the jar will probably be named fubar.jar before you publish >>> it. Then the publish ant task would have a revision of 1.0-SNAPSHOT, >>> so when it's published, the jar would then be fubar-1.0-SNAPSHOT.jar >>> in your repository (depending on your repository pattern). >>> >>> On Mon, Sep 27, 2010 at 7:03 AM, David Harrigan <dharri...@gmail.com> wrote: >>>> I see, so, if I put something like: >>>> >>>> fubar-1.0-SNAPSHOT.jar >>>> >>>> at the end of my jar and publish that, ivy should (after a bit of >>>> further tweaking) pick up on that? >>>> >>>> I'll give it a whirl later and let you all know. Thanks all for your >>>> replies. >>>> >>>> -=david=- >>>> >>>> On 26 September 2010 16:34, Mitch Gitman <mgit...@gmail.com> wrote: >>>>> This is something I stumbled on myself, but depending on >>>>> "latest.integration" actually resolves a module with a status of >>>>> integration >>>>> OR GREATER. So, using the default set of statuses, "latest.integration" >>>>> will >>>>> get the latest module, whether its status is release or milestone or >>>>> integration. >>>>> >>>>> The default status is integration if you don't specify one for ivy:deliver >>>>> or ivy:publish. The documentation refers to an ivy.status property when it >>>>> comes to how ivy:deliver/ivy:publish defaults the status but doesn't >>>>> mention >>>>> what that property's own default value is. There is an ivy.status.default >>>>> property as well. >>>>> >>>>> On Sun, Sep 26, 2010 at 8:01 AM, James Davis <james.da...@atsid.com> >>>>> wrote: >>>>> >>>>>> Additionally, the status of the artifact may need to be set to >>>>>> integration. >>>>>> As I understand it, latest integration pulls the latest version of an >>>>>> artifact that has a status of integration. However, I am not sure what >>>>>> the >>>>>> default module status is though (have not looked at the docs to confirm). >>>>>> >>>>>> James Davis • QA Engineer II/Software Engineer >>>>>> Applied Technical Systems, Inc. • Systems Division >>>>>> web: www.atsid.com • e-mail: james.da...@atsid.com >>>>>> (p) 360.698.7100 x241 • (f) 360.698.7200 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> I prefer encrypted and signed messages. KeyID: B20A22F9 >>>> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9 >>>> >>> >> >> >> >> -- >> I prefer encrypted and signed messages. KeyID: B20A22F9 >> Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9 >> > -- I prefer encrypted and signed messages. KeyID: B20A22F9 Fingerprint: 110A F423 3647 54E2 880F ADAD 1C52 85BF B20A 22F9
