ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@yahoo.com>
Subject Re: onsuccess or onfailure
Date Tue, 14 Apr 2009 18:50:54 GMT

I'll add some comments inline:

--- On Tue, 4/14/09, Eric Fetzer <elstonkers@yahoo.com> wrote:

> From: Eric Fetzer <elstonkers@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 <gudnabrsam@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 <elstonkers@yahoo.com>
> wrote:
> 
> > From: Eric Fetzer <elstonkers@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 <gudnabrsam@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 <elstonkers@yahoo.com>
> > wrote:
> > 
> > > From: Eric Fetzer <elstonkers@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 <gudnabrsam@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 <elstonkers@yahoo.com>
> > > wrote:
> > > 
> > > > From: Eric Fetzer <elstonkers@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 <gudnabrsam@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 <elstonkers@yahoo.com>
> > > > wrote:
> > > > 
> > > > > From: Eric Fetzer <elstonkers@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 <gudnabrsam@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 <elstonkers@yahoo.com>
> > > > > wrote:
> > > > > 
> > > > > > From: Eric Fetzer <elstonkers@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 <gudnabrsam@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
> <elstonkers@yahoo.com>
> > > > > > wrote:
> > > > > > 
> > > > > > > From: Eric Fetzer <elstonkers@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-unsubscribe@ant.apache.org
> > > > > > For additional commands, e-mail:
> user-help@ant.apache.org
> > > > > > 
> > > > > > 
> > > > > >      
> > > > > 
> > > > > 
> > > > >      
> > > > > 
> > > > >
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > > > > For additional commands, e-mail: user-help@ant.apache.org
> > > > > 
> > > > > 
> > > > >      
> > > > 
> > > > 
> > > >      
> > > > 
> > > >
> > >
> >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > > > For additional commands, e-mail: user-help@ant.apache.org
> > > > 
> > > > 
> > > >      
> > > 
> > > 
> > >      
> > > 
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > > For additional commands, e-mail: user-help@ant.apache.org
> > > 
> > > 
> > >      
> > 
> > 
> >      
> > 
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > For additional commands, e-mail: user-help@ant.apache.org
> > 
> > 
> >      
> 
> 
>       
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> For additional commands, e-mail: user-help@ant.apache.org
> 
> 
>       


      

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org


Mime
View raw message