> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Erik already brought that up. Target foo imported from project named > bar is known as "foo" in my build file unless I override it (in which > case it becomes "bar.foo". I'd like to have the alias name "bar.foo" > available even if I don't override it. > > I haven't looked into the code yet, but are there any principal > objections? Target time-frame would be 1.6.2.
Kinda... This allows to bypass the target override, and thus bypass whatever the overridden target does. It's kind of like allowing any class in Java to use C++'s Class::method(), i.e. static binding when dynamic binding to any overridden method() was the intent. Or perhaps I misunderstand the issue. I guess I don't understand the purpose of this. Targets are akin to Java interfaces to me, i.e. they define a contract, and if a 'derived' build script overrides target A for example, what's the meaning of this same build script also calling base.A (outside of the derived A itself), or worse, what's the meaning of a further derived2 script to call base.A, bypassing derived.A (derived2 imports derived, which import base)? I'm not -1, and even then it'd be non-binding, but I don't understand the need for this. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]