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
