Not suggesting this as the solution, just interesting to see how close we could get with what exists right now. I wonder if using two different antlib declarations would work / or be a workaround?
xmlns:*ivy_scope_1*="antlib:fr.jayasoft.*ivy*.*ant*" xmlns:*ivy_scope_2*="antlib:fr.jayasoft.*ivy*.*ant*" I *think* it should windup putting ivy classes in sibling classloaders. I would have to try it, someone more familiar with ant and namespaces would know better than I. The idea is that you still have just 1 implicit "scope" for each ivy, so whatever you do with ivy_scope_1: wouldn't be seen by ivy_scope_2:, and vice-versa. They are naturally isolated by defining classloader. It might just be a stupid ant trick, but it might be a simple way to separate concerns. I understand Stephane's example right, the lifecycle build.xml might just work on ivy_scope_1, and when a project decides it needs to retrieve some packaging tools in some overridden task, it might do that with ivy_scope_2 which would keep it from messing up ivy_scope_1 when its publication time. Its tricky because the ant properties are global to all the ant task classloaders, so this probably depends on weather ivy copies the value of a property to some internal state or not. It may also be harder for some users to consume since you need to understand a little more about Ant and namespaces. On 12/27/06, Xavier Hanin <[EMAIL PROTECTED]> wrote:
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 > >
-- - Eric
