ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Fetzer <elstonk...@yahoo.com>
Subject Re: onsuccess or onfailure
Date Mon, 13 Apr 2009 22:05:36 GMT
Does trycatch have to be internal to a target?  I tried:

<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 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


      
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message