I agree too. I think we should open an issue about this problem to keep track about it. We may find a way to address it even with a backward solution, by providing a mean to set in which "scope" (as Stephane suggest) an ivy task should be done. Without providing this scope, a default one would be used. Shouldn't be too difficult to implement.
Xavier On 12/27/06, Gilles Scokart <[EMAIL PROTECTED]> wrote:
I agree. I have similar concerns. See http://mail-archives.apache.org/mod_mbox/incubator-ivy-dev/200611.mbox/%3ce9 [EMAIL PROTECTED] (Damn, it's rather difficult to put a link to a previous mail). My proposition (maybe for 2.0, who knows?) was to replace the implicit objects stored as 'hidden references' by explicit references that can be managed by the user, and passed as argument of each task. Gilles > -----Original Message----- > From: Stephane Bailliez [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 27, 2006 2:41 PM > To: [email protected] > Subject: 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
