[
https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-366.
-------------------------------
Resolution: Fixed
> Scope and status leakage during build lifecycle
> -----------------------------------------------
>
> Key: IVY-366
> URL: https://issues.apache.org/jira/browse/IVY-366
> Project: Ivy
> Issue Type: Improvement
> Components: Ant, Core
> Affects Versions: 1.4.1
> Reporter: Stephane Bailliez
> Assignee: Maarten Coene
> Fix For: 2.0.0-alpha-2
>
> Attachments: IVY-366-settings-scoping-2.patch,
> IVY-366-settings-scoping-3.patch, IVY-366-settings-scoping-4.patch,
> IVY-366-settings-scoping.patch
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.
