On Tuesday 12 August 2003 13:24, Stefan Bodewig wrote:
> On Tue, 12 Aug 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Tuesday 12 August 2003 12:36, Stefan Bodewig wrote:
> >> On Fri, 1 Aug 2003, peter reilly <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
