[ http://issues.apache.org/jira/browse/IVY-366?page=comments#action_12461172 ] Gilles Scokart commented on IVY-366: ------------------------------------
I see two level of scopes : the configuration scope, and the resolution scope. The scope you mention herebefore is the resolution scope where a sub-project make a new resolve/retrieve that shoul be be scoped separately. The configuration scope is a scope where you allow sub-project to use an other configuration (might have a different repository, or might have different conflict handler, or ...). I think an elegant way to implement that is to create two ant data types (exist already +/-, but are not clearly exposed to ant scripts): 1. An IvyEngine that can be used to scope the configuration 2. An IvyResolution that can be used to scope the resolve/retrieve. Like others ant datatypes, those object have a id that can be reference by the user in his script. Every post-resolve task should accept an IvyResolution refid. Every other task that rely on the configuration should accept a IvyEngine refid. A default value can be configured for backaward compatibility reasons. The IvyEngine objects would be created by the configure task, and the IvyResolution objects will be created by a resolve (or a retrieve). An additional id parameter will have to be added to those tasks. (Here also, a default value is possible). Alternatively, you can also imagine a more declarative aproach where your IvyEngine and IvyResolution can be declared anywhere as standalone data type, and referenced by task the tasks that should be scoped by them. > Scope and status leakage during build lifecycle > ----------------------------------------------- > > Key: IVY-366 > URL: http://issues.apache.org/jira/browse/IVY-366 > 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 way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
