Xavier Hanin wrote:
I agree too. I think we should open an issue about this problem to keep
track about it. We may find a way to address it even with a backward
solution, by providing a mean to set in which "scope" (as Stephane
suggest)
an ivy task should be done. Without providing this scope, a default one
would be used. Shouldn't be too difficult to implement.
/me thinks you would have to get rid of Ivy singleton to do that
effectively.
And there are 2 uses cases, either you are dealing with 2 scopes.
(source / target) or one scope (implicitely source=target)
Or you force to do another configure to avoid this 2-scope thing.
Forget a minute about the dodgy syntax below, but for example
Example 1 (which is basically what is done right now, I'm using 'main'
to be explicit) :
<ivy:configure scope='main'... />
...
<ivy:resolve scope='main'.. /> look for information in the 'main' scope
and set properties in the 'main' scope
Example 2 (resolving in one scope with a central ivy configuration):
<ivy:configure scope='main'... />
...
<ivy:resolve scope='main'.. /> look for information in the 'main' scope
and set properties in the 'main' scope
<ivy:resolve ivy='main' scope='binary'.. /> set properties in the
'binary' scope...but uses ivy configured in scope 'main'.
-- stephane
