[jira] Updated: (IVY-366) Scope and status leakage during build lifecycle

["Gilles Scokart (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gilles Scokart updated IVY-366:
-------------------------------

    Attachment: IVY-366-settings-scoping.patch

Here is a patch that add a support for ivy:settings and scoping of the settings.

It patch the code, the doc and the examples (src\example\build-a-ivy-repository is a good example where you can see the scoping in action).

I didn't updated the 'screenshots' in the tutorial (by the way, they are reather old...)

There is still a pending issue with the scoping of the http authentication done in the settings.

In the doc, I mentioned 'since 2.0'.  I hope it is the right number.

I guess I didn't have to say it, but you certainly have to review the english grammar of my doc, sory.

Ho.. and I just realised that I didn't mention in the doc that all the ant properties are now used by ivy, except when they are explicitly overwritten in ivy settings (or with a var task).  Concerning that, note that ant properties have the priority over 'non overwrite' ivy variables. It means that ivy variable can be overwritten by ant variables (is it what we want??).


> 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
>         Assigned To: Maarten Coene
>         Attachments: 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.