ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <>
Subject Re: return early from a macrodef?
Date Sat, 11 Nov 2006 00:52:51 GMT
At 04:38 PM 11/10/2006, you wrote:
 >Jake: Why [can't you/are you reluctant to] use target
 >dependencies to do this as opposed to macros?

Hi Matt,

Please read [1] (see below).

For further explanation, In my generic core build file, I call the 
<bootstrap/> macrodef.  I don't want the generic build file having to 
know what <bootstrap/> does except by implication.  Right now I've 
got ant-contrib, which is considered required for the build.  I may 
add other libraries that I consider required.  The macrodef exists 
inside an external antlib file loaded like this...

<typedef file="${rootdir}/common-build.antlib" format="xml" 

I have a minimum set of targets in common build....

      <target name="prepare" depends="appinfo, -prepare.hook, -prepare.local"/>
     <target name="-prepare.hook" depends="-prepare.hook.bootstrap"/>
     <target name="-prepare.hook.bootstrap">
     <target name="appinfo" depends="-appinfo.local"
             description="displays application info about the current build"/>

I have plugin import files that add their own targets as dependencies 
of "-prepare.hook" or "-prepare.hook.bootstrap" (via a custom 
scriptdef).  The latter target is what a download plugin might hook 
into.  It might obtain ant-contrib.jar from the net and put the jar 
in its place on the file system.  The very last thing that happens, 
after all plugins have completed their bootstrapping targets, is the 
call to <cmn:bootstrap/>.   The build requires ant-contrib, so it 
can't be a plugin that provides the bootstrapping.  The bootstrapping 
needs to be called out from the common build file that every other 
non-plugin build file imports.  I never want to touch this common 
build file for any reason.  It provides a common infrastructure and 
that's it;  no specifics!  And besides the fact that adding 
dependency targets on "-prepare.hook.bootstrap" to perform checks for 
ant-contrib existing in the classpath or checks for a Path with an 
"ant-contrib" id would expose implementation to the common build 
file, it also makes it so plugins have to worry about whether they 
append or prepend target dependencies to make sure they don't break 
the common build infrastructure.

Now, as I've explained before (see [1]), the main problem is that the 
<typedef onerror="ignore"> fails to actually ignore a missing 
classpathref.  The build fails.  If a user decides to put 
ant-contrib.jar in ${user.home}/.ant/lib, I don't want to have to 
force them to create a Path with an Id of "ant-contrib".  However, 
that's needed if they haven't put ant-contrib in .ant/lib.

The only solution I see, given <typedef onerror="ignore"> 
uselessness, is to write a script in a scriptdef that can be called 
and force an early return from the macrodef this custom typedef was 
called from if a particular condition is met.

I hope I've explained myself.   In any case, it doesn't much matter 
*why* I want to do it.  What matters is whether my desired 
functionality is even possible.  Can you provide any insight 
there?  Any implementation details?




 >--- Jacob Kjome <> wrote:
 >> Quoting John Norvell <>:
 >> >
 >> extension library has the
 >> > <if> task that uses conditions.   Would you be
 >> able to use that?
 >> >
 >> Curiously enough, the whole point of needing to be
 >> able to do this is to
 >> bootstrap ant-contrib without requiring it to be in
 >> a user's
 >> ${user.home}/.ant/lib directory.  If it is there,
 >> then I'd just like to use it
 >> (and not force the user, in this case, to define a
 >> path with an id called
 >> "ant-contrib".  See more on this below). If not,
 >> then I'd typedef it with a
 >> user-defined path, with the id "ant-contrib", which
 >> would be required in the
 >> absence of ant-contrib.jar in .ant/lib.  It's all
 >> about flexibility.
 >> Now, there would be no problem typedefing the
 >> ant-contrib stuff if missing
 >> classpathrefs didn't cause failure even when the
 >> typedef's onerror is "ignore"
 >> or "report".  But it does fail, so I need to check
 >> if the reference is defined.
 >>  This would be the condition I mentioned previously.
 >> So, as you can see, I need to be able to do this
 >> little bit without the help of
 >> ant-contrib, since it won't be available until I
 >> bootstrap it.  Hence, the
 >> quest to find a way to return early from a macrodef,
 >> which is where I put the
 >> <typedef>, to avoid invoking the <typedef> when
 >> ant-contrib.jar is already in
 >> .ant/lib.  Hence, avoiding the need force users to
 >> provide the path with id
 >> "ant-contrib", which would have the ant-contrib.jar
 >> as one of its path
 >> elements.
 >> Besides this specific case, I can see an early
 >> return as being generally useful
 >> anyway.  So I'm quite curious to find out if it is
 >> possible using a scriptdef.
 >> For more detailed info on typedef failing with a
 >> missing classpathref, even when
 >> onerror is "ignore" or "report", see my previous
 >> post from a few days ago that
 >> never got answered...
 >> Jake
 >> > -J
 >> >
 >> > Jacob Kjome wrote:
 >> > >
 >> > > In a macrodef, if I check a condition and that
 >> condition is true, I'd like
 >> > to
 >> > > return early from the macrodef and not run any
 >> of the rest of its contents.
 >> >  Is
 >> > > it possible using a <scriptdef> to write a
 >> script that can force an early
 >> > return
 >> > > from the <sequential> part of the macrodef if
 >> the condition is met?  This
 >> > is
 >> > > kind of akin to an if/unless on a target.  I'm
 >> not quite seeing where I
 >> > would
 >> > > be able to hook into Ant to do such a thing.  Is
 >> it impossible?  I hope
 >> > not.
 >> > >
 >> > > BTW, I'm not talking about <fail/>.  I don't
 >> want the build to end when the
 >> > > condition is met.  I just want to skip the rest
 >> of the <macrodef> contents
 >> > and
 >> > > continue processing.
 >> > >
 >> > >
 >> > > Jake
 >> > >
 >> > >
 >> > > To unsubscribe, e-mail:
 >> > > For additional commands, e-mail:
 >> > >
 >> > >
 >> >
 >> >
 >> >
 >> > To unsubscribe, e-mail:
 >> > For additional commands, e-mail:
 >> >
 >> To unsubscribe, e-mail:
 >> For additional commands, e-mail:
 >Do you Yahoo!?
 >Everyone is raving about the all-new Yahoo! Mail beta.
 >To unsubscribe, e-mail:
 >For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message