Why use retrieve + standard ant path creation over cachepath?

[Dave <da...@gmail.com>]

In the Ivy documentation for the <ivy:cachepath> task, it suggests
*"Please prefer the use of retrieve + standard ant path creation, which make
your build more independent from ivy (once artifacts are properly retrieved,
ivy is not required any more)."*

Do most people follow this retrieve+ant practice? Cachepath worked well for
me when a module + all of it's dependencies were resolved from the same
location, but it had issues when the module was resolved from multiple
repositories.

Regards,
Dave

-- 
There are 10 types of people in the world.
Those who understand binary and those who do not.

Re: Reducing the number of resolves

[Xavier Hanin <xa...@gmail.com>]

On Wed, Jun 18, 2008 at 4:52 AM, Nascif Abousalh-Neto <
Nascif.AbousalhNeto@sas.com> wrote:

> Hi all,

Hi Nascif,


>
>
> We are trying to reduce the number of resolves that a developer needs to do
> during its daily development cycle. Specially when hitting a remote
> repository, the time that a resolve takes adds up and affects productivity.
>
> We looked into decoupling resolves from compilation + publish (to local
> repo, for multi-projects in a developer playpen) but one of the issues we
> have is the indirect dependency from a publish to the last resolve executed
> by the client. The publish (or to be precise, the deliver) relies on state
> left in memory by the last resolve. But since neither publish nor deliver
> allows the specification of a resolveId, there is very little flexibility
> left to really break up the steps.
>
> When we tried that it became easy for a second resolve to be executed in
> the middle and "corrupt" the state that would be used for the publish. The
> result can be quite unsettling, like jars being published to the wrong
> module!
>
> Is this a known problem? I couldn't find anything about it in Jira. If so,
> is there any recommended workaround?

There is way to reuse result from a last resolve in any post resolve task,
but this is not using a resolveId, which is used to isolate several resolves
occuring in the same build. What you need is provide organisation and module
attributes on your post resolve task. You can easily get them using the
ivy:info task. I just see that this is not documented, so it's not easy to
find. I hope it still works with Ivy 2, I haven't checked for a long time.
Please report any problem.

Xavier




-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Reducing the number of resolves

[Nascif Abousalh-Neto <Na...@sas.com>]

Hi all,

We are trying to reduce the number of resolves that a developer needs to do during its daily development cycle. Specially when hitting a remote repository, the time that a resolve takes adds up and affects productivity.

We looked into decoupling resolves from compilation + publish (to local repo, for multi-projects in a developer playpen) but one of the issues we have is the indirect dependency from a publish to the last resolve executed by the client. The publish (or to be precise, the deliver) relies on state left in memory by the last resolve. But since neither publish nor deliver allows the specification of a resolveId, there is very little flexibility left to really break up the steps.

When we tried that it became easy for a second resolve to be executed in the middle and "corrupt" the state that would be used for the publish. The result can be quite unsettling, like jars being published to the wrong module!

Is this a known problem? I couldn't find anything about it in Jira. If so, is there any recommended workaround?

Re: Why use retrieve + standard ant path creation over cachepath?

[Jing Xue <ji...@digizenstudio.com>]

On Mon, Jun 16, 2008 at 11:59:41AM +0100, Dave wrote:
> In the Ivy documentation for the <ivy:cachepath> task, it suggests
> *"Please prefer the use of retrieve + standard ant path creation, which make
> your build more independent from ivy (once artifacts are properly retrieved,
> ivy is not required any more)."*
> 
> Do most people follow this retrieve+ant practice? Cachepath worked well for
> me when a module + all of it's dependencies were resolved from the same
> location, but it had issues when the module was resolved from multiple
> repositories.

I used to do cachepath because it's obviously the easiest, but soon
became annoyed by the fact that even recompiling one changed class would
take 30 seconds to resolve to begin with.

So now my build script only resolves once, and then "retrieves" by
creating links to the artifacts in cache (to avoid the redundant copies).
During resolving, all classpaths for the configurations are recorded, so
that during regular (i.e. offline) builds they can be reconstructed
without having to run another resolve.

Cheers.
-- 
Jing Xue

RE: Why use retrieve + standard ant path creation over cachepath?

["Fernandes, Gerard" <ge...@lehman.com>]

Personally, I use retrieve only for packaging and cachepath for
development. 

This suits our requirements - your requirements may dictate a different
approach.

-----Original Message-----
From: Dave [mailto:davidcorley@gmail.com] 
Sent: 16 June 2008 12:00
To: ivy-user@ant.apache.org
Subject: Why use retrieve + standard ant path creation over cachepath?

In the Ivy documentation for the <ivy:cachepath> task, it suggests
*"Please prefer the use of retrieve + standard ant path creation, which
make your build more independent from ivy (once artifacts are properly
retrieved, ivy is not required any more)."*

Do most people follow this retrieve+ant practice? Cachepath worked well
for me when a module + all of it's dependencies were resolved from the
same location, but it had issues when the module was resolved from
multiple repositories.

Regards,
Dave

--
There are 10 types of people in the world.
Those who understand binary and those who do not.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

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.

Re: Why use retrieve + standard ant path creation over cachepath?

[Colin Fleming <co...@gmail.com>]

Hey Dave,

We've always used cachepath. Well, we're actually using the Ivy API
from Java code, but the idea is the same. It's never given us any real
problems, although when porting the code to the beta API (with the
separate artifact and resolution resolvers) we had to re-work it a
bit. We use retrieve to build copies of our application that we can
distribute, but for development and QA we only use artifacts directly
from the cache.

Cheers,
Colin