ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: [Patch] namespace and antlib
Date Thu, 14 Aug 2003 05:45:28 GMT
peter reilly wrote:

> On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote:
>> On Tue, 12 Aug 2003, peter reilly <peter.reilly@corvil.com> wrote:
>> > On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote:
>> >> On Fri, 1 Aug 2003, peter reilly <peter.reilly@corvil.com> wrote:
>> >> >   <typedef resource="net/sf/antcontrib/antlib.xml"
>> >> >            uri="antlib:net.sf.antcontrib"
>> >> >            classpath="/tmp/ant-contrib.jar"/>
>> >>
>> >> wouldn't the resource attribute be redundant in that case?
>> >
>> > Not in this case. The automatic lookup of
>> > uri="antlib:net.sf.antcontrib" to net/sf/antcontrib/antlib.xml
>> > resource currently is done once when the ns prefix is encountered
>> > the first time - it does not take place at the <typedef/> task.
>>
>> The obvious question would be: Why not?
> The code handles build scripts like:
> 
> <project xmlns:ac="antlib:net.sf.antcontrib"> (1)
>    <ac:shellscript shell="bash">   (2)
>       echo helloworld
>     </ac:shellscript>
> 
>     <typedef uri="antlib:net.sf.antcontrib"  (3)
>                   name="shellscript"
>                   classpath="testing.classes"
>                   classname="net.sf.antcontrib.pending.ShellScriptNew"/>
> 
>     <ac:shellscript shell="bash"  (4)
>           echo helloword from test shellscript
>     </ac:shellscript>
> </project>
> 
> (1) will associate the ns prefix "ac" with the uri
> "antlib:net.sf.antcontrib" (2) ComponentHelper#createComponent will call
> #checknamespace for
>     antlib:net.sf.antcontrib and maps it to the
>     net/sf/antcontrib/antlib.xml resource. It then creates a typedef task,
>     and sets the uri and resource to "antlib:..." and "net/sf..." and sets
>     the onerror parameter to "ignore", this will make available the
>     antcontrib's definitions.
>      ComponentHelper stores the fact that it has implicitly loaded in
>      these definitions so that it does not do this again.
> 3) This will override the antcontribs' uris definition of shellscript.
> 4) This will execute the new definition.


All this overriding may create some bad maintaince problems. I wish we
wouldn't support this feature... 


Costin




> 
>> > I have changed this to ant:*,
>>
>> Hmm, what will be the replacement for antlib:*?
> 
> Users are allowed to use antlib:*. The restricted uri's are uris
> that users are not allowed to use in <typedef/>.
>>
>> > as I found when testing that the current code reserves antcontrib:
>> > and antelope: ....
>>
>> Sure, I don't see a problem, though.
>>
>> > This makes sense, but would involve some messing with classloaders
>> > and scanning of the jar files in ANT_HOME/antlibs.
>>
>> I know.
>>
>> > Each time I look at classloaders, my head melts down....
>>
>> You are not alone ;-)
>>
>> Seriously, once you've started to really look into classloaders they
>> are not that bad.  Only hard to do right (I'm not sure whether I've
>> ever done so 8-).
> There are sure a lot of things to keep in mind, junit support, classpath
> delagate, antclassloader, project#setCoreLoader() (not used??) etc ;-)
> Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message