ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fernandes, Gerard" <gerard.fernan...@lehman.com>
Subject RE: Publish to local vs Retrieved from cache
Date Wed, 23 Jan 2008 12:58:05 GMT

The "useOrigin" attribute tells Ivy to reference the artefact via the
origin (repository) path. This works if your repository is local
(AFAICT).

If:
(a) you are using a local repository, and
(b) your artefact version numbers are guaranteed to be always different
for each built artefact

the above solution should be fine.

I myself use this in conjunction with the version set to
"latest.integration" on my built artefacts and it works for me. Since I
use a CVS repository for 3rd party libs, my "repository" is always
local.

If either of (a) or (b) above is not true, you need to be aware that the
cache will come into play and you will then need to either:
(a) guarantee distinct version numbers per build (which can be a good
thing actually, depending on your work process/methodology), 

Or

(b) remember to nuke your local cache whenever an existing version of a
built artefact is "patched" (rebuilt with changed classes)

Or

(c) set Ivy up to recognise time-stamps (there is a "changing" attribute
that can be specified somewhere, and there is a way of configuring
"snapshot" versions as well).

I personally haven't done (c) as my process deviates a bit from the
ideal in this regard. Therefore I can't shed more light on that option.

If you use Eclipse+IvyDE, bear in mind that IvyDE always goes via the
cache (at least the last stable release does) - so you may have strange
problems in Eclipse. To work around you can either:
(a) Set up all projects with appropriate dependencies "exported" in
Eclipse. This will ensure dependent projects are dependent on the IDE
built classes path and Ivy is used for 3rd party artefacts only.
(b) Nuke your cache defensively every time a dependent artefact changes.

Gerard Fernandes.

-----Original Message-----
From: esumerfd@gmail.com [mailto:esumerfd@gmail.com] On Behalf Of Edward
Sumerfield
Sent: 22 January 2008 15:49
To: IvyUsers
Subject: Re: Publish to local vs Retrieved from cache

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 <gerard.fernandes@lehman.com>
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: esumerfd@gmail.com [mailto:esumerfd@gmail.com] 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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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.




Mime
View raw message