ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vimil Saju <vimils...@yahoo.com>
Subject Re: Self-referencing Antlib limitation
Date Sun, 16 Sep 2012 16:03:59 GMT
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.lalevee@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-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message