incubator-ivy-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephane Bailliez (JIRA)" <>
Subject [jira] Commented: (IVY-366) Scope and status leakage during build lifecycle
Date Wed, 03 Jan 2007 12:10:27 GMT


Stephane Bailliez commented on IVY-366:

I think it is simple and flexible to not clutter the code and usage.

> Scope and status leakage during build lifecycle
> -----------------------------------------------
>                 Key: IVY-366
>                 URL:
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Ant, Core
>    Affects Versions: 1.4.1
>            Reporter: Stephane Bailliez
> Writing this to keep track of the problem following mail in dev@:
> Just a couple of lines about something that has been bothering me for a long time.
> Ivy stores a lot of properties (including an instance of itself after configure) while
running, and other tasks add properties on their way as well.
> I don't like very much this as it prevents to do separation of concerns between ivy instances,
and resolve calls for example as it basically provides you a couple of nice way to shoot yourself
in the foot rather transparently. A minor mistake is enough to make you scratch your head
for some time.
> The typical example would be that I have a common build xml which provides all the lifecycle
needed for most projects.
> It is doing the resolve for standardized conf and types.
> Projects can override some targets to add their own dependencies and retrieve them.
> Typical example would be to retrieve a binary file (or whatever which is not used for
compilation but for running/packaging)
> Which basically means that it must do its own resolve/retrieve call and thus will interfere
with the properties that have already been set. So the packaging, publishing process (which
is later in the cycle) , may actually be altered by the fact that I have ran a different set
of ivy calls.
> NB: This information leakage is particulary evil when you're doing a complex build with
different setups where you're doing subant calls. It becomes very very hard to make sure you're
not doing something wrong.
> At first I would say: "Would be nice to at least have 'scopes' but there might be a better

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:


View raw message