You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Nascif Abousalh-Neto <Na...@sas.com> on 2008/06/18 04:52:11 UTC

Reducing the number of resolves

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: Reducing the number of resolves

Posted by 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/