peter reilly wrote: > 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
