Rhino
I would suggest calling the sound within a specific task which executes
depending on the presence a property (if="property")
or absence of property (unless="property")
HTH,
Martin-
----- Original Message -----
From: "Rhino" <[EMAIL PROTECTED]>
To: "Ant Users List" <[EMAIL PROTECTED]>
Sent: Sunday, October 24, 2004 3:37 PM
Subject: Re: Need guidance re <fail>
> First of all, thanks for the very useful reply, Erik!
>
> I suppose I've just been thinking of things the wrong way. As you pointed
> out, a reasonably clear message does appear when a particular task fails.
> I'm already using <echo> tasks where it is appropriate to give my user
> information on what is happening at critical moments of my build.
>
> I had already read the article on <sound> and thought I more-or-less
> understood it but I've just reread it and find that I'm not so sure I get
it
> after all. I'm confused about the if/unless parameters in the examples
> provided, particularly how they are set elsewhere in the build. I find the
> presence of the if/unless confusing. It seems to me that a well-written
> build would want the <sound> task run every time the build takes place and
> then place the success sound if everything worked or the failure sound if
> some part of the build failed. But the example seems to be making the
target
> conditional, which doesn't make sense to me. Can you please explain that
to
> me?
>
> For ease of discussion, I'm providing a barebones version of one of my
> builds, with the main structure preserved but virtually all of the meat
> stripped from the bones. (In other words, it doesn't do anything except
> <echo> and playing sounds; it doesn't do any compiling, deleting of files,
> etc.) I have some remarks and then some questions below the example.
>
> <?xml version="1.0" ?>
>
> <project name="Sound" default="end" basedir="D:\eclipse\workspace">
>
> <description>Experiment with the sound task so that one sound is played
>
> if the build works and another sound is played if it fails.
>
> </description>
>
> <property name="sound.success" value="c:\Windows\Media\sir.wav"/>
>
> <property name="sound.failure" value="c:\Windows\Media\ALLWRONG.wav"/>
>
> <!--==============================================================
>
> Display the values of the properties.
>
> ==============================================================-->
>
> <target name="init" description="Initialization.">
>
> <tstamp prefix="start">
>
> <format property="TODAY" pattern="EEEE, MMM dd, yyyy"/>
>
> <format property="TIME" pattern="hh:mm a"/>
>
> </tstamp>
>
> <echo message="This Ant script began executing at ${start.TIME} on
> ${start.TODAY}."/>
>
> <!--echoproperties description="Display all properties."/-->
>
> </target>
>
> <!--==============================================================
>
> Determine which server is the target.
>
> ==============================================================-->
>
> <target name="getserver" description="Determine which server is the
target">
>
> <input message="Which server should receive the files? 1. Sympatico 2.
> Tonge"
>
> validargs="1,2"
>
> addproperty="server.choice"
>
> defaultvalue="2"/>
>
> <condition property="servername" value="Sympatico">
>
> <equals arg1="${server.choice}" arg2="1"/>
>
> </condition>
>
> <condition property="servername" value="Tonge">
>
> <equals arg1="${server.choice}" arg2="2"/>
>
> </condition>
>
> </target>
>
> <!--==============================================================
>
> Load the properties file for the appropriate server.
>
> ==============================================================-->
>
> <target name="getprops" depends="getserver" description="Get the
appropriate
> properties file depending on the server which was chosen">
>
> <property
> file="${workspace}\${resume.proj}\xml\server.${servername}.properties"/>
>
> </target>
>
> <!--==============================================================
>
> Get the userid and password for the desired server.
>
> ==============================================================-->
>
> <target name="getlogin" depends="getprops" description="Get userid and
> password for server.">
>
> <input message="Please supply the userid for the ${servername} server:"
> addproperty="userid" defaultvalue="dougb"/>
>
> <input message="Please supply the password for the ${servername} server:"
> addproperty="password" defaultvalue="dougbpw"/>
>
> </target>
>
> <!--==============================================================
>
> Execute the appropriate upload target, depending on which server
>
> was chosen.
>
> ==============================================================-->
>
> <target name="echo" depends="getlogin" description="Upload to the selected
> server.">
>
> <antcall target="echo-${servername}"/>
>
> </target>
>
> <!--==============================================================
>
> Upload to the Sympatico server.
>
> ==============================================================-->
>
> <target name="echo-Sympatico" description="Upload to the Sympatico
server.">
>
> <echo message="Uploading to Sympatico...."/>
>
> </target>
>
> <!--==============================================================
>
> Upload to the Tonge server.
>
> ==============================================================-->
>
> <target name="echo-Tonge" description="Upload to the Tonge server.">
>
> <echo message="Uploading to Tonge...."/>
>
> </target>
>
> <!--==============================================================
>
> Cleanup tasks for the script.
>
> ==============================================================-->
>
> <target name="end" depends="init,echo" description="Tasks that should
always
> be run upon completion of the build.">
>
> <echo message="The resume has been successfully uploaded to the
> ${servername} server."/>
>
> <sound description="Play success or failure sounds, whichever is
> appropriate">
>
> <success source="${sound.success}"/>
>
> <fail source="${sound.failure}"/>
>
> </sound>
>
> </target>
>
> </project>
>
> Remarks:
> There are only a few things that can go wrong in this simple example. For
> instance, I can fail to provide any input for the two <input> tasks in the
> 'getlogin' target (by pressing the Cancel button). I suppose there would
> also be errors if the specified property file doesn't exist when I do the
> 'echo' target.
>
> Question:
> My idea of how <fail> and <sound> work together *was* as follows: if all
of
> the build steps work, when we get to the 'end' target, the success sound
> would be played. If *any* of the build steps failed, the build would
branch
> to the 'end' target and play the failure sound.
>
> I'm starting to see that things wouldn't/couldn't work this way. However,
> I'm not quite clear on what I would have to do to the 'end' target and
> 'getlogin' targets to make that happen.
>
> Can someone tell me what changes I would need to make to get the behaviour
I
> want? (Assuming it is *possible* to get the behaviour I want! If it isn't
> possible, what CAN behaviour can I get that would be reasonably similar
and
> how would I get it?)
>
> Rhino
>
>
> ----- Original Message -----
> From: "Erik Hatcher" <[EMAIL PROTECTED]>
> To: "Ant Users List" <[EMAIL PROTECTED]>
> Sent: Sunday, October 24, 2004 6:57 AM
> Subject: Re: Need guidance re <fail>
>
>
> On Oct 22, 2004, at 9:26 AM, Rhino wrote:
> > One of the aspects that I want to improve is error handling. Right
> > now, I mostly just assume that everything is going to work and don't
> > do much error handling; if the build fails, it fails.
>
> This is really the Ant "way". Failure is a built-in mode of operation
> and handled appropriately already (I think).
>
> > However, I'd like to polish things to the point where, if any task
> > (or at least target) fails for some reason, that a message specifying
> > the nature of the problem is displayed and a specific error sound is
> > played.
>
> As for a message - you already get that. Is that not sufficient? If
> not, check out using the -logger or -listener command-line switch.
>
> For sound, check out the <sound> task:
>
> http://ant.apache.org/manual/OptionalTasks/sound.html
>
> > The problem is that the documentation on <fail> leaves a lot to the
> > imagination.
>
> <fail> is not really what you want to use given what you're asking for.
> Failure is built-in. A task fails, the build fails (generally
> speaking, that is). And the error message shown is descriptive enough
> to act upon.
>
> > I'm not at all clear on how I make my script branch to a <fail> task
> > and then generate a message specific to the task which actually
> > failed. A message that says "Your build failed" is a lot less useful
> > to me than one that says "The second compile task of target ABC failed
> > because you ran out of memory."
>
> Add an <echo> at appropriate points (before each compile in this case)
> saying <echo>First compile...</echo> and <echo>Second
> compile...</echo>. You'd then see explicitly where things were. But,
> perhaps it'd be better to have your two compiles in separate targets,
> making it explicitly clear which one failed.
>
> As for running out of memory - don't you see that stated pretty clearly
> with the exception thrown?
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
