I'll add some comments inline:
--- On Tue, 4/14/09, Eric Fetzer <elstonk...@yahoo.com> wrote:
> From: Eric Fetzer <elstonk...@yahoo.com>
> Subject: Re: onsuccess or onfailure
> To: "Ant Users List" <user@ant.apache.org>
> Date: Tuesday, April 14, 2009, 12:08 PM
> OK, getting closer but no cigar
> yet. So does a property get set on failure? For example,
> if I run the following with -k, I would think it would go
> into target1, target2, and then onfailure, but instead it
> goes into each target:
>
>
> <project default="main">
> <target name="target1">
> <echo message="In target1"/>
I placed these <fail>s to give you a way to force a failure; this exhibits the
keepgoing behavior to illustrate that a failure will fail the build even though
it keeps trying to run targets.
> <fail if="failtarget1" />
> </target>
Using unless="failure" implies that something in your build may set a property
called "failure". Ant will not do any magical thing that NAnt may have trained
you to expect.
HTH,
Matt
> <target name="target2" unless="failure">
> <echo message="In target2"/>
> <copy todir="../dirThatDoesntExist">
> <fileset
> dir="anotherDirThatDoesntExist"/>
> </copy>
> <fail if="failtarget2" />
> </target>
> <target name="target3" unless="failure">
> <echo message="In target3"/>
> <fail if="failtarget3" />
> </target>
> <target name="onsuccess" unless="failure">
> <echo message="successful"/>
> </target>
> <target name="onfailure" if="failure">
> <echo message="failure"/>
> </target>
> <target name="main"
> depends="target1,target2,target3,onsuccess,onfailure" />
> </project>
>
>
>
>
>
> ________________________________
> From: Matt Benson <gudnabr...@yahoo.com>
> To: Ant Users List <user@ant.apache.org>
> Sent: Monday, April 13, 2009 4:26:55 PM
> Subject: Re: onsuccess or onfailure
>
>
>
>
> --- On Mon, 4/13/09, Eric Fetzer <elstonk...@yahoo.com>
> wrote:
>
> > From: Eric Fetzer <elstonk...@yahoo.com>
> > Subject: Re: onsuccess or onfailure
> > To: "Ant Users List" <user@ant.apache.org>
> > Date: Monday, April 13, 2009, 5:05 PM
> > Does trycatch have to be internal to
> > a target? I tried:
> >
>
> trycatch is a task. You cannot contain targets inside a
> task. You can specify any number of tasks outside of a
> target; these will be added to the anonymous default
> target--this makes it easy to make quick & dirty
> buildfiles that do a single thing, great for abusing Ant to
> do all sorts of things other than what it was designed for.
>
> > <project name="build" default="main">
> > <taskdef
> >
> resource="net/sf/antcontrib/antcontrib.properties"/>
> > <trycatch>
> > <try>
> > <target name="main"
> > depends="target1,target2,target3" />
> >
> > <target name="target1">
> > <echo message="In target1"/>
> > </target>
> >
> > <target name="target2">
> > <echo message="In target2"/>
> > <copy todir="../dirThatDoesntExist">
> > <fileset
> > dir="anotherDirThatDoesntExist"/>
> > </copy>
> > </target>
> > <target name="target3">
> > <echo message="In target3"/>
> > </target>
> > </try>
> > <catch>
> > <echo message="failure"/>
> > <fail message="${failure}"/>
> > </catch>
> >
> > <finally>
> > <echo message="successful"/>
> > </finally>
> > </trycatch>
> >
> > </project>
> >
> > but it never hit my default target, flew straight into
> the
> > catch and then to the finally... It doesn't seem
> there's a
> > prescribed way for defining what happens after
> something
> > fails in Ant other than leave. The way you
> restructured
> > my code earlier never hits the onfailure target
> either. I
>
> The example I gave you depends on your detecting failures
> and setting the "failure" property appropriately. Once
> again, if all you're trying to do on failure is send an
> email, you might best served by the MailLogger. If you
> planned to use the keepgoing option you could use a success
> property instead of a failure property:
>
> <project default="main">
>
> <target name="target1">
> <echo message="In target1"/>
> <fail if="failtarget1" />
> <property name="success1"
> value="nobodycareswhatmyvalueis" />
> </target>
>
> <target name="target2">
> <echo message="In target2"/>
> <fail if="failtarget2" />
> <property name="success2"
> value="nobodycareswhatmyvalueis" />
> </target>
>
> <target name="target3">
> <echo message="In target3"/>
> <fail if="failtarget3" />
> <property name="success3"
> value="nobodycareswhatmyvalueis" />
> </target>
>
> <target name="checksuccess">
> <condition property="success"
> value="nobodycareswhatmyvalueis">
> <and>
> <isset property="success1" />
> <isset property="success2" />
> <isset property="success3" />
> </and>
> </condition>
> </target>
>
> <target name="onsuccess" if="success">
> <echo message="successful"/>
> </target>
>
> <target name="onfailure" unless="success">
> <echo message="failure"/>
> </target>
>
> <target name="main"
> depends="target1,target2,target3,checksuccess,onsuccess,onfailure"
> />
>
> </project>
>
> This example begins to get a bit silly, but it works.
> Each target includes a built-in failure mechanism to play
> with. Specify e.g. 'ant -Dfailtarget1=anyvalue' and the
> build will fail on target1. Add -k to that and all three
> targets will be executed before the success/failure is also
> evaluated.
>
> -Matt
>
> > don't want the targets to keep running when something
> fails,
> > I just want to be able to clean up shop and send an
> email
> > with logs to the appropriate folks. Otherwise, I
> have to
> > peek back at the command line every once in a while or
> wrap
> > the Ant call so that I can get a return code...
> >
> >
> >
> >
> > ________________________________
> > From: Matt Benson <gudnabr...@yahoo.com>
> > To: Ant Users List <user@ant.apache.org>
> > Sent: Monday, April 13, 2009 2:46:34 PM
> > Subject: Re: onsuccess or onfailure
> >
> >
> > Those steps 1 and 2 are mutually exclusive.
> Personally I
> > wouldn't recommend the step 2 approach. Step 2
> simply
> > tells you to put the jar someplace sensible so you can
> use
> > it. I still wouldn't bind a buildfile to a
> directory
> > location; either bundle ant-contrib with your project
> so
> > that your buildfile can find it from its basedir, or
> use the
> > other built-in facilities to manage included
> libraries.
> > Specifically, read the user manual Running Ant >
> Library
> > Directories and Running Ant > Environment Variables
> for
> > more information on automatic library management.
> >
> > -Matt
> >
> > P.S. Never use CLASSPATH! ;)
> >
> > --- On Mon, 4/13/09, Eric Fetzer <elstonk...@yahoo.com>
> > wrote:
> >
> > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > Subject: Re: onsuccess or onfailure
> > > To: "Ant Users List" <user@ant.apache.org>
> > > Date: Monday, April 13, 2009, 3:34 PM
> > > I'm an old dog, but I can learn new
> > > tricks (even become friends with depends).
> > >
> > > So I'm trying to work out the <trycatch>
> stuff,
> > but
> > > first I've got to get antcontrib wired up. I've
> done
> > step
> > > 1 which is obvious. Where is step 2 referring
> to
> > (i.e.
> > > what file do I place that code in?
> > >
> > > 1. Copy ant-contrib-0.3.jar to the lib
> > > directory of your Ant installation. If you want
> to use
> > one
> > > of the tasks in your own project, add the lines
> > > <taskdef
> > >
> >
> resource="net/sf/antcontrib/antcontrib.properties"/>
> > > to your build file.
> > > 2. Keep ant-contrib-0.3.jar in a
> > > separate location. You now have to tell Ant
> explicitly
> > where
> > > to find it (say in /usr/share/java/lib):
> > > <taskdef
> > >
> >
> resource="net/sf/antcontrib/antcontrib.properties">
> > > <classpath>
> > > <pathelement
> > >
> >
> location="/usr/share/java/lib/ant-contrib-0.3.jar"/>
> > > </classpath>
> > > </taskdef>
> > >
> > >
> > >
> > > ________________________________
> > > From: Matt Benson <gudnabr...@yahoo.com>
> > > To: Ant Users List <user@ant.apache.org>
> > > Sent: Monday, April 13, 2009 9:18:34 AM
> > > Subject: Re: onsuccess or onfailure
> > >
> > >
> > > If there is an actual build failure in any
> target
> > execution
> > > will end, unless you run Ant in keepgoing mode
> (I
> > believe
> > > that is command-line option -k). You could
> instead
> > use
> > > ant-contrib's <try> task to catch
> > BuildExceptions and
> > > defer their processing until the end. Finally,
> note
> > that
> > > antcall should pretty much be used when nothing
> else
> > will
> > > work. In particular it won't work for what
> you're
> > trying
> > > to do because, as antcall actually executes a
> > different
> > > Project instance, any properties set in called
> targets
> > will
> > > not be available in your top level/calling
> project.
> > For
> > > the same reasons, antcall is a memory and time
> > waster. I
> > > personally consider it deprecated and haven't
> used
> > antcalls
> > > since macrodefs became available--I have not yet
> found
> > the
> > > problem that (prior to Ant 1.6) required an
> antcall,
> > but
> > > couldn't be solved (after Ant 1.6) with a
> macrodef.
> > If you
> > > insist you simply hate using target
> dependencies,
> > despite
> > > the fact that that's precisely what
> > > they
> > > are for, you could consider using ant-contrib's
> > antcallback
> > > task; this allows properties to be set in the
> calling
> > > project, though it does not solve the
> memory/speed
> > issues
> > > introduced by using a separate project instance.
>
> > Another
> > > thing to note is that for those times when you
> really
> > do
> > > want to use multiple <antcall>s, you
> should
> > consider
> > > using multiple nested <target> elements in
> a
> > single
> > > <antcall> for efficiency (ac antcallback
> does
> > not
> > > support this, however). Depends are really
> okay!
> > They're
> > > the Ant way!
> > >
> > > HTH,
> > > Matt
> > >
> > > --- On Mon, 4/13/09, Eric Fetzer <elstonk...@yahoo.com>
> > > wrote:
> > >
> > > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > > Subject: Re: onsuccess or onfailure
> > > > To: "Ant Users List" <user@ant.apache.org>
> > > > Date: Monday, April 13, 2009, 9:24 AM
> > > > Thanks Matt! So if in target2 it
> > > > fails out, it will still make it to target3?
>
> > In
> > > NAnt, when
> > > > it fails anywhere, that's it unless there's
> an
> > > onfailure
> > > > declared... Would it still work my way (I
> > don't
> > > like
> > > > depends because of readability):
> > > >
> > > > <target name="main">
> > > > <antcall target="target1"/>
> > > > <antcall target="target2"/>
> > > > <antcall target="target3"/>
> > > > <antcall target="onsuccess"/>
> > > > <antcall target="onfailure"/>
> > > > </target>
> > > >
> > > > <target name="target1">
> > > > <echo message="In target1"/>
> > > > </target>
> > > >
> > > > <target name="target2">
> > > > <echo message="In target2"/>
> > > > </target>
> > > >
> > > > <target name="target3">
> > > > <echo message="In target3"/>
> > > > </target>
> > > >
> > > > <target name="onsuccess"
> unless="failure">
> > > > <echo message="successful"/>
> > > > </target>
> > > >
> > > > <target name="onfailure"
> if="failure">
> > > > <echo message="failure"/>
> > > > <fail message="${failure}"/>
> > > > </target>
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > ________________________________
> > > > From: Matt Benson <gudnabr...@yahoo.com>
> > > > To: Ant Users List <user@ant.apache.org>
> > > > Sent: Friday, April 10, 2009 2:55:24 PM
> > > > Subject: Re: onsuccess or onfailure
> > > >
> > > >
> > > > <project default="main">
> > > >
> > > > <target name="target1">
> > > > <echo message="In target1"/>
> > > > </target>
> > > >
> > > > <target name="target2">
> > > > <echo message="In target2"/>
> > > > </target>
> > > >
> > > > <target name="target3">
> > > > <echo message="In target3"/>
> > > > </target>
> > > >
> > > > <target name="onsuccess"
> > unless="failure">
> > > > <echo message="successful"/>
> > > > </target>
> > > >
> > > > <target name="onfailure"
> if="failure">
> > > > <echo message="failure"/>
> > > > <!-- make it more obvious the build
> > failed"
> > > />
> > > > <fail message="${failure}"/>
> > > > </target>
> > > >
> > > > <target name="main"
> > > >
> > depends="target1,target2,target3,onsuccess,onfailure"
> > > />
> > > >
> > > > </project>
> > > >
> > > > You can test the failure state by
> specifying
> > > > -Dfailure=anyvalue on the command line.
> You
> > might
> > > like the
> > > > NoBannerLogger (does not log quiet/skipped
> > targets)
> > > with
> > > > this example. Also, as far as mailing
> build
> > results
> > > goes,
> > > > the MailLogger may help you.
> > > >
> > > > HTH,
> > > > Matt
> > > >
> > > > --- On Fri, 4/10/09, Eric Fetzer <elstonk...@yahoo.com>
> > > > wrote:
> > > >
> > > > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > > > Subject: Re: onsuccess or onfailure
> > > > > To: "Ant Users List" <user@ant.apache.org>
> > > > > Date: Friday, April 10, 2009, 3:45 PM
> > > > > I don't get this Matt. Can you fix
> > > > > the following to be what you're
> talking
> > about:
> > > > >
> > > > > <target name="main">
> > > > > <antcall target="target1"/>
> > > > > <antcall target="target2"/>
> > > > > <antcall target="target3"/>
> > > > > <antcall target="onsuccess"/>
> > > > > <antcall target="onfailure"/>
> > > > > </target>
> > > > >
> > > > > <target name="target1">
> > > > > <echo message="In target1"/>
> > > > > </target>
> > > > >
> > > > > <target name="target2">
> > > > > <echo message="In target2"/>
> > > > > </target>
> > > > >
> > > > > <target name="target3">
> > > > > <echo message="In target3"/>
> > > > > </target>
> > > > >
> > > > > <target name="onsuccess"
> unless="somehow
> > I
> > > know
> > > > all
> > > > > tasks were successful">
> > > > > <echo message="successful"/>
> > > > > </target>
> > > > >
> > > > >
> > > > >
> > > > > <target name="onfailure"
> unless="somehow
> > I
> > > > > know something failed">
> > > > > <echo message="failure"/>
> > > > > </target>
> > > > >
> > > > >
> > > > > To me, I don't see any way to get to
> > another
> > > target
> > > > once it
> > > > > fails out of one. The onsuccess, yes,
> but
> > not
> > > > > onfailure...
> > > > >
> > > > > Thanks for having patience with me
> Matt!
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > ________________________________
> > > > > From: Matt Benson <gudnabr...@yahoo.com>
> > > > > To: Ant Users List <user@ant.apache.org>
> > > > > Sent: Friday, April 10, 2009 9:19:44
> AM
> > > > > Subject: Re: onsuccess or onfailure
> > > > >
> > > > >
> > > > > --- On Fri, 4/10/09, Eric Fetzer <elstonk...@yahoo.com>
> > > > > wrote:
> > > > >
> > > > > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > > > > Subject: Re: onsuccess or
> onfailure
> > > > > > To: "Ant Users List" <user@ant.apache.org>
> > > > > > Date: Friday, April 10, 2009, 9:32
> AM
> > > > > > Sorry, I should have given you
> more
> > > > > > detail. It does exactly what it
> says.
> >
> > > When
> > > > the
> > > > > build
> > > > > > fails (i.e. a target that isn't
> set
> > for
> > > > > onfailure="false"
> > > > > > fails) or finishes with success,
> it
> > > immediately
> > > > calls
> > > > > the
> > > > > > target specified. In my example,
> it
> > would
> > > call
> > > > > either the
> > > > > > onsuccess or onfailure targets.
> Very
> > > useful to
> > > > me
> > > > > because
> > > > > > I want to send emails, unlock
> files in
> > > StarTeam,
> > > > scan
> > > > > > logs... for onfailure, but not
> for
> > success.
> > > > >
> > > > > In Ant you would ordinarily structure
> your
> > > target
> > > > > dependencies such that onsuccess and
> > onfailure
> > > were
> > > > always
> > > > > part of the graph, but would use
> target
> > > if/unless
> > > > attributes
> > > > > to en/disable them at RT. Alternately
> you
> > might
> > > be
> > > > able to
> > > > > write a custom target Executor to do
> > something
> > > like
> > > > what
> > > > > NAnt does, but I wouldn't necessarily
> > recommend
> > > that
> > > > > approach.
> > > > >
> > > > > HTH,
> > > > > Matt
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > > > From: Matt Benson <gudnabr...@yahoo.com>
> > > > > > To: Ant Users List <user@ant.apache.org>
> > > > > > Sent: Thursday, April 9, 2009
> 4:24:12
> > PM
> > > > > > Subject: Re: onsuccess or
> onfailure
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --- On Thu, 4/9/09, Eric Fetzer
> <elstonk...@yahoo.com>
> > > > > > wrote:
> > > > > >
> > > > > > > From: Eric Fetzer <elstonk...@yahoo.com>
> > > > > > > Subject: onsuccess or
> onfailure
> > > > > > > To: "Ant Users" <user@ant.apache.org>
> > > > > > > Date: Thursday, April 9,
> 2009,
> > 2:42 PM
> > > > > > > Hi! I'm an ex-NAnt user
> coming
> > over
> > > > > > > to the Ant side. Most
> things
> > are
> > > close to
> > > > > identical,
> > > > > > but I
> > > > > > > have a question about
> something
> > I'm
> > > not
> > > > > finding. In
> > > > > > NAnt,
> > > > > > > you can create properties:
> > > > > > >
> > > > > > > <property
> > name="nant.onsuccess"
> > > > > > value="onsuccess"/>
> > > > > > > <property
> > name="nant.onfailure"
> > > > > > value="onfailure"/>
> > > > > > >
> > > > > > > which will go to the
> > corresponding
> > > onsuccess
> > > > or
> > > > > > onfailure
> > > > > > > targets when finished based
> on
> > whether
> > > it
> > > > > succeeded
> > > > > > or
> > > > > > > not. I'm sure there is the
> > equivalent
> > > in
> > > > Ant,
> > > > > but
> > > > > > have
> > > > > > > been unable to find it.
> Can
> > someone
> > > please
> > > > give
> > > > > me a
> > > > > > link
> > > > > > > or such?
> > > > > > >
> > > > > >
> > > > > > This smells of some NAnt-ness
> quite
> > foreign
> > > to
> > > > Ant.
> > > > > > Personally speaking, I need more
> > > information
> > > > about
> > > > > what
> > > > > > these properties are supposed to
> do
> > before I
> > > can
> > > > offer
> > > > > any
> > > > > > useful advice.
> > > > > >
> > > > > > -Matt
> > > > > >
> > > > > > > Thanks,
> > > > > > > Eric
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > > > > > For additional commands, e-mail:
> user-h...@ant.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > > > > For additional commands, e-mail: user-h...@ant.apache.org
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > > > For additional commands, e-mail: user-h...@ant.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > > For additional commands, e-mail: user-h...@ant.apache.org
> > >
> > >
> > >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> > For additional commands, e-mail: user-h...@ant.apache.org
> >
> >
> >
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
> For additional commands, e-mail: user-h...@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@ant.apache.org
For additional commands, e-mail: user-h...@ant.apache.org
