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]

Reply via email to