I think that since the code doesn't address the primary usecase, that
trumps pretty-well all considerations. It is hard to imagine how
someone would be relying on the order of the extension point/extension
evaluation in order to avoid the extension point. Since the behaviour
isn't documented anyway, doing so would have to be considered a hack.
I'd say make it do what it is supposed to do. If it passes gump, then we
can wait to see if any bug reports show up. If they do, we can deal with
those on a case-by-case basis, perhaps arriving at a wholly different
solution for them. Personally, I don't think any will show up.
On 23/04/2010 2:29 AM, Stefan Bodewig wrote:
Hi all,
currently extension-point and import don't play together like they are
supposed to. You can't extend an imported extension point with a target
from the importing build file (which is the primary use-case, really).
Attached to this bug is a patch that fixes the problem (including an
AntUnit test that fails in 1.8.0).
The same patch breaks a different AntUnit test, namely
testExtensionPointMustBeKnown in extension-point-test.xml. This test
asserts that you can't extend an extension point from the same build
file before that extension point has been defined. I.e. you can't do
<target name="bar" extensionOf="foo"/>
<extension-point name="foo"/>
Personally I think the changed behavior isn't a bad thing, the old
behavior isn't documented and we shouldn't even try to keep it.
What do you think?
Stefan
PS: I'd love to see this fixed with Ant 1.8.1.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
