You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "Stephane Bailliez (JIRA)" <ji...@apache.org> on 2006/12/28 09:08:20 UTC
[jira] Created: (IVY-366) Scope and status leakage during build
lifecycle
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
[jira] Updated: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "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-2.patch
My previous patch contains a bug when you are using default settings. The variable set in the constructor of IvySettings were removed when the AntVariableContainer was set.
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486259 ]
Gilles Scokart commented on IVY-366:
------------------------------------
Small remark when used with subant build :
- If the user reuse the same settings reference, he should not redefine the task in an other classloader in the subbuild. (documentation added in doc/doc/use/settings.html in the patch).
- If the user reuse a parent settings reference in the subbuild, the patch I provided keep the settings linked to the parent (that includes baserdir !). (This is not yet documented in the patch).
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486261 ]
Xavier Hanin commented on IVY-366:
----------------------------------
I'd like to be sure I understand correctly: by linked to the parent, you mean that the settings Variable Container is attached to the parent ant project, and thus properties values will be taken from the parent, right? Is there any other kind of link to parent ant project?
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486344 ]
Xavier Hanin commented on IVY-366:
----------------------------------
You're right!
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486327 ]
Gilles Scokart commented on IVY-366:
------------------------------------
Actually, in previous version we had a default IvySettings (well, it was ivyConf) per classloader defining the ivy tasks, which is not the same as one per ant project. I think I should manage to make something similar.
I will post a third version of the patch taking that into account when it is done.
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484748 ]
Xavier Hanin commented on IVY-366:
----------------------------------
I don't have time right now to review the whole patch in detail, but after a quick glance it seems like a very good job. Thanks for your contribution!
For the 'screenshots', this is not a problem, I think we'll have to update them all just before we release the final 2.0 version. Re running all tutorials will be necessary anyway, so it's better to avoid wasting time updating them at each modification.
For the english grammar, I guess I don't have to say I won't be able to review it :-)
For priorities about properties/variables, I second your decision, it's how it was working before.
Now to apply the patch, Maarten you're the assignee of this issue... Can you apply the patch if you review it with no objection?
> 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486790 ]
Maarten Coene commented on IVY-366:
-----------------------------------
ok, I'll wait for your new patch to apply it
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486265 ]
Gilles Scokart commented on IVY-366:
------------------------------------
You have understood correctly.
I don't know if those two things will be intuitive for the user. If it just need to be documented or if an other aproach should be taken.
> 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-2.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ 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
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Gilles Scokart (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486115 ]
Gilles Scokart commented on IVY-366:
------------------------------------
Oups, I forgot to select 'licensed for inclusion in ASF works'. Consider it is.
> 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-2.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.
[jira] Work started: (IVY-366) Scope and status leakage during
build lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on IVY-366 started by Maarten Coene.
> 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
>
> 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.
[jira] Updated: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "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-3.patch
The third patch now take care of the default settings. Finally, it is neither by project, neither by classloader. It is a mix.
In this patch, there is a default id "ivy.instance". But when we use it, we check that it has the correct class (thus correct classloader). If not, we recreate a new default one.
> 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-2.patch, IVY-366-settings-scoping-3.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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Stephane Bailliez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461940 ]
Stephane Bailliez commented on IVY-366:
---------------------------------------
I think it is simple and flexible to not clutter the code and usage.
> 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
>
> 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: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maarten Coene reassigned IVY-366:
---------------------------------
Assignee: Maarten Coene
> 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
>
> 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12485001 ]
Maarten Coene commented on IVY-366:
-----------------------------------
I'm still working on the scoping of the resolve.
I'm at the moment trying to have a correct behaviour for the post-resolve task. In order to do this properly, I have made some local changes which I'll have to commit first. I'll do that as soon as I think the post-resolve task works properly with resolve scoping.
After that, I'll have a look at your patch.
> 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479255 ]
Xavier Hanin commented on IVY-366:
----------------------------------
Good work Maarten! I've just fixed a little issue in IvyTask (a forgotten replacement of MessageImpl used, and a missing parameter in one ensureResolved method.
One thing I'd like to discuss: why remove XmlReportOutputter.getReportFileName? Changing the signature to take a resolveId would have been better, no? Because now you have some piece of code (like ResolveTest) which constructs the file name themselves.
> 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
>
> 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.
[jira] Updated: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "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:
-------------------------------
Fix Version/s: 2.0.0-alpha-2
For me, I have finished. The settings can now be scoped. The only thing still pending is the scoping of the credentialStore. I will raise an other issue for that one specifically.
> 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461788 ]
Xavier Hanin commented on IVY-366:
----------------------------------
I like your idea Gilles! It would be clean and very flexible. Would this be a good solution for you, Stephane?
> 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
[jira] Updated: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12496304 ]
Xavier Hanin commented on IVY-366:
----------------------------------
I've just checked in your patch, Gilles, with minor modifications to adapt to latest trunk. Tests are passing, I've also modified our own build to use ivy:settings instead of ivy:configure, everything seems to work properly.
I'll let you mark the issue resolved when you and Maarten will agree to say so.
Now that you're an official member of the team I don't thank you explicitly for your contribution any more, but you know what I think :-)
> 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-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.
[jira] Updated: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "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-4.patch
Here is a new version of the patche after the merge with the most recent trunk.
I have also reset ivy:settings to a dataype, but ivy:configure is a task.
I have flagged ivy:configure as deprecated, but to make to move easiest, I have put the settingsRef attribute optional (it reference ivy:instance by default).
I think you should easily change what is deprected or not by just adding some traces and a few lines in the doc.
> 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-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.
[jira] Resolved: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Maarten Coene (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478942 ]
Maarten Coene commented on IVY-366:
-----------------------------------
I've committed some changes to SVN to ease implementing a solution for this:
- Added 'resolveId' concept to ivy core.
- Modified ant tasks to use this resolveId while keeping old behaviour as default.
The changes to the ant tasks are not complete yet and needs some more testing. I'll do that the next couple of days...
> 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
>
> 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.
[jira] Commented: (IVY-366) Scope and status leakage during build
lifecycle
Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVY-366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12486274 ]
Xavier Hanin commented on IVY-366:
----------------------------------
I think this solution is pretty fine if we make it backward compatible. To be backward compatible, I think we have to provide some way to workaround the classloader issue. Indeed in 1.4.1 I think it was possible to load new settings in each sub project, even if a first settings was loaded in the parent. So in this case I think we'd need to use a different settingsId in each subproject. Maybe making the default settingsId dependent on the project name in which it's loaded would make sense?
I'm not really sure, I think we'd need to define some use cases and make some tests to see if:
* the solution is backward compatible
* we can address the use cases without too much trouble
If we fulfill these requirements, I think good documentation (maybe a new tutorial, or an update to the multi-project one) should be enough.
> 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-2.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.