Thanks. I added the useOrigin="true" attribute on the retrieve task which did the trick.
Now I presume this is different the date time check that you mentioned. Do you fore see any issues with this solution instead? On Jan 22, 2008 6:29 AM, Fernandes, Gerard <[EMAIL PROTECTED]> wrote: > > The 'publish' task will always publish to the repository - which in your > case seems to be '.ivy2/local'. For the newly published artefacts to get > into your cache, a client project needs to request it via a 'resolve' > task. The 'resolve' task will then 'download' the newly published > artefacts to the local cache. > > Either the version numbers need to change for Ivy to detect that the > artefact is indeed a newer version than what is available in the cache, > or you need to set Ivy up to use the time-stamp on the artefact (I > believe there is an attribute 'changing' or some such that can be used > to tell Ivy to pick up newer time-stamped artefacts). > > Gerard Fernandes > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Edward > Sumerfield > Sent: 21 January 2008 23:24 > To: IvyUsers > Subject: Publish to local vs Retrieved from cache > > I have just started publishing jars from one project and making then > dependents to others. This works well except there is some kind of > caching issue. > > The publish appears to place the jars in .ivy2/local to be picked up and > copied to .ivy2/cache. Now when a new jar is published to local it is > not updated in cache? What is the best way to handle this? > > -- > Ed > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > - - - - - - - > > This message is intended only for the personal and confidential use of the > designated recipient(s) named above. If you are not the intended recipient > of this message you are hereby notified that any review, dissemination, > distribution or copying of this message is strictly prohibited. This > communication is for information purposes only and should not be regarded as > an offer to sell or as a solicitation of an offer to buy any financial > product, an official confirmation of any transaction, or as an official > statement of Lehman Brothers. Email transmission cannot be guaranteed to be > secure or error-free. Therefore, we do not represent that this information > is complete or accurate and it should not be relied upon as such. All > information is subject to change without notice. > > > > -- Ed
