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
