On Thursday 14 August 2003 06:45, Costin Manolache wrote: > 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...
This is for backward's compatiblity - <taskdef/> and <typedef/> have always worked this way. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]