You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-dev@incubator.apache.org by Stephane Bailliez <sb...@gmail.com> on 2006/12/27 13:40:48 UTC
Scope and status leakage during build lifecycle
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 way.
Xavier, I suppose you have been thinking about this already ?
-- stephane