Re: Self-referencing Antlib limitation
Le 16 sept. 2012 à 18:03, Vimil Saju a écrit :
Isn't it possible to use the ant:current uri to solve this issue, as
described in the link below?
http://ant.apache.org/manual/Types/antlib.html
Nice catch, I forgot about that. Probably antunit needs to be fixed.
But what about the antunit test I have committed disabled ? Should we consider
it a valid use case ? Or should we consider a bug and promote the use of
'current' ?
I am in favor of the later, so we can avoid some tricky code.
Nicolas
From: Nicolas Lalevée nicolas.lale...@hibnet.org
To: Ant Developers List dev@ant.apache.org
Sent: Sunday, September 16, 2012 7:21 AM
Subject: Self-referencing Antlib limitation
I was still playing with classloaders and namespaces and antlib import with
the AntDSL, and I encountered an unexpected limitation.
What I found: an antlib which is referencing itself in its definition cannot
be loaded dynamically via an uri other than its antlib one.
This is the case for antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
[...]
taskdef name=fail
classname=org.apache.ant.antunit.AssertTask/
[...]
macrodef name=assertTrue backtrace=false
attribute name=message default=Assertion failed/
element name=assertion implicit=true/
sequential
au:fail message=@{message}
assertion/
/au:fail
/sequential
/macrodef
And the following doesn't work:
taskdef classpath=antunit.jar uri=urn:antunit
resource=org/apache/ant/antunit/antlib.xml /
(actually, this precise line works, but trying to use any antunit macro will
fail)
I think that the issue is how Ant interpret the namespace declaration in the
antlib definition. In Antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
When Ant is parsing it, it considers it as an antlib to be resolved later,
whereas it should detect that this is the canonical uri of the antlib it is
parsing, or sort of this, and should use the uri actual used rather than
the antlib one.
The behavior only affect cases where somebody is trying to load two different
versions of the same antlib. This is some quite edge case, but do we agree
this is an issue ?
I have committed a test case to see it in action. See r1385269. To run it,
rename first broken_testURI to testURI in
src/tests/antunit/taskdefs/taskdef-antlib-test.xml.
I had a quick look to how to fix it. As far I can tell, the best way to do it
is to:
* in Definer.loadAntlib(ClassLoader, URL), make the createAntlib aware of the
resource it was loaded from, and try to build an antlib uri from that.
* in Antlib.createAntlib(), let the projecthelper parse the file to an
unknown element with the 'incorrect' uri. But then make a deep lookup in the
tree of UnknownElements and change everything that needs to be changed.
It seems not trivial.
Let me know what you think.
Nicolas
-
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
Self-referencing Antlib limitation
I was still playing with classloaders and namespaces and antlib import with the
AntDSL, and I encountered an unexpected limitation.
What I found: an antlib which is referencing itself in its definition cannot be
loaded dynamically via an uri other than its antlib one.
This is the case for antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
[...]
taskdef name=fail
classname=org.apache.ant.antunit.AssertTask/
[...]
macrodef name=assertTrue backtrace=false
attribute name=message default=Assertion failed/
element name=assertion implicit=true/
sequential
au:fail message=@{message}
assertion/
/au:fail
/sequential
/macrodef
And the following doesn't work:
taskdef classpath=antunit.jar uri=urn:antunit
resource=org/apache/ant/antunit/antlib.xml /
(actually, this precise line works, but trying to use any antunit macro will
fail)
I think that the issue is how Ant interpret the namespace declaration in the
antlib definition. In Antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
When Ant is parsing it, it considers it as an antlib to be resolved later,
whereas it should detect that this is the canonical uri of the antlib it is
parsing, or sort of this, and should use the uri actual used rather than the
antlib one.
The behavior only affect cases where somebody is trying to load two different
versions of the same antlib. This is some quite edge case, but do we agree this
is an issue ?
I have committed a test case to see it in action. See r1385269. To run it,
rename first broken_testURI to testURI in
src/tests/antunit/taskdefs/taskdef-antlib-test.xml.
I had a quick look to how to fix it. As far I can tell, the best way to do it
is to:
* in Definer.loadAntlib(ClassLoader, URL), make the createAntlib aware of the
resource it was loaded from, and try to build an antlib uri from that.
* in Antlib.createAntlib(), let the projecthelper parse the file to an unknown
element with the 'incorrect' uri. But then make a deep lookup in the tree of
UnknownElements and change everything that needs to be changed.
It seems not trivial.
Let me know what you think.
Nicolas
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Self-referencing Antlib limitation
Isn't it possible to use the ant:current uri to solve this issue, as
described in the link below?
http://ant.apache.org/manual/Types/antlib.html
From: Nicolas Lalevée nicolas.lale...@hibnet.org
To: Ant Developers List dev@ant.apache.org
Sent: Sunday, September 16, 2012 7:21 AM
Subject: Self-referencing Antlib limitation
I was still playing with classloaders and namespaces and antlib import with the
AntDSL, and I encountered an unexpected limitation.
What I found: an antlib which is referencing itself in its definition cannot be
loaded dynamically via an uri other than its antlib one.
This is the case for antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
[...]
taskdef name=fail
classname=org.apache.ant.antunit.AssertTask/
[...]
macrodef name=assertTrue backtrace=false
attribute name=message default=Assertion failed/
element name=assertion implicit=true/
sequential
au:fail message=@{message}
assertion/
/au:fail
/sequential
/macrodef
And the following doesn't work:
taskdef classpath=antunit.jar uri=urn:antunit
resource=org/apache/ant/antunit/antlib.xml /
(actually, this precise line works, but trying to use any antunit macro will
fail)
I think that the issue is how Ant interpret the namespace declaration in the
antlib definition. In Antunit:
antlib xmlns:au=antlib:org.apache.ant.antunit
When Ant is parsing it, it considers it as an antlib to be resolved later,
whereas it should detect that this is the canonical uri of the antlib it is
parsing, or sort of this, and should use the uri actual used rather than the
antlib one.
The behavior only affect cases where somebody is trying to load two different
versions of the same antlib. This is some quite edge case, but do we agree this
is an issue ?
I have committed a test case to see it in action. See r1385269. To run it,
rename first broken_testURI to testURI in
src/tests/antunit/taskdefs/taskdef-antlib-test.xml.
I had a quick look to how to fix it. As far I can tell, the best way to do it
is to:
* in Definer.loadAntlib(ClassLoader, URL), make the createAntlib aware of the
resource it was loaded from, and try to build an antlib uri from that.
* in Antlib.createAntlib(), let the projecthelper parse the file to an unknown
element with the 'incorrect' uri. But then make a deep lookup in the tree of
UnknownElements and change everything that needs to be changed.
It seems not trivial.
Let me know what you think.
Nicolas
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
