ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: [Patch] namespace and antlib
Date Tue, 12 Aug 2003 13:09:27 GMT
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.

> > 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