Re: [PATCH] Several improvements to Zip and Jar tasks - comment

[Sh...@lotus.com]

Excellent point - I've been meaning to make a feature request for Ant:  add
a '-k' flag a'la make: keep going in the face of errors.

It would be nice to control this both on the task level and on the top
level.  In some cases, the makefile writer will know that some tasks might
be critical, and that others are 'nice to have' in normal use but not
really necessary.  On the other hand, users running Ant to do builds will
sometimes will want to either 1) just try to do everything, for when you're
testing locally or just trying out a few new changes, or 2) halt on any
sort of error, for when you're creating a distribution unit you plan to
ship later.

I think I like the idea of making this settable on each task.  On the
grander scale, I'm not sure the best way for a user running Ant to set
this.

---- you Mark Rose <ma...@gforce.com> wrote: ----
> Generally, I'd prefer all tasks to fail and halt the build if there's
> any sort of problem, since we have builds that generate hundreds or

P.S. (Sorry if this has already been asked): are there archives of ant-dev
and/or the other jakarta projects?

- Shane

Re: [PATCH] Several improvements to Zip and Jar tasks - comment

[Jesse Glick <Je...@netbeans.com>]

Shane_Curcuru@lotus.com wrote:
> Excellent point - I've been meaning to make a feature request for Ant:  add
> a '-k' flag a'la make: keep going in the face of errors.
> [snip]
> I think I like the idea of making this settable on each task.  On the
> grander scale, I'm not sure the best way for a user running Ant to set
> this.

Suggestion: as a (backwards-compatible) alternative to the "depends"
attribute of <target>, make an option to insert a nested <dependencies>
element, with subelements <dependency target="xxx"/> and so on. This is
more XML-ish anyway than a comma-separated list. Now add an optional
attribute to <dependency>, failonerror, a boolean. Default "true", in
which case behave as now (BuildException from a task cancels the build).
If "false", and the *dependency* target throws a BuildException, log it
at highest (error) level, but then continue and run the current target
anyway.

Advantages of this scheme:

- Failures in a task in the middle of a target will always cancel the
rest of the target. Since targets are usually the conceptual units and
need to be sequential, this only makes sense.

- Failure mode is placed in dependencies, not targets or tasks or
anywhere else, since the basic question is whether to continue or not,
and this is a property of the dependency. For example, one target may
require another to have been successful or it too will surely fail;
other targets may want the previous target to have been run, but can
proceed without it as well.

- If you really want just one task to be failure-insensitive, you can
easily break apart the target into a pre-target, a target with that
task, and a post-target, depend on all three with the middle dependency
"soft".

- Build script authors can specify exactly which dependencies should be
hard and which soft.

- But, if it could go either way, they may use e.g.:

	<dependency target="make-docs" failonerror="${production}"/>

which will force production builds to always complete, but be more lax
for test runs. You can choose some convention for this variable name and
use it for many dependencies if you like.

- Reasonably simple model for what the attribute controls: if false, Ant
will try to run this target first, but if it does not work, it will not
stop the build. If true, it will stop the build.

Another alternative, with no core changes required, is to make
<calltarget> or whatever this is called take an optional failonerror
parameter and otherwise behave as above: if false, build exceptions from
the subtarget are logged but not rethrown. I think the functionality is
essentially the same, so this might be more attractive. Or, give
<calltarget> further target-valued attributes such as 'catch' and
'finally' which would do the obvious things (run handler code in case of
a BuildException, and clean up after the target, resp.). But this is
arguably more confusing and there is no easy way to switch the
ignore-error mode on or off using properties, as with 'failonerror'.

Comments?

-Jesse

-- 
Jesse Glick   <ma...@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Re: [PATCH] Several improvements to Zip and Jar tasks - comment

[Peter Donald <do...@mad.scientist.com>]

At 12:41  17/8/00 -0400, you wrote:
>---- you Mark Rose <ma...@gforce.com> wrote: ----
>> Generally, I'd prefer all tasks to fail and halt the build if there's
>> any sort of problem, since we have builds that generate hundreds or
>
>P.S. (Sorry if this has already been asked): are there archives of ant-dev
>and/or the other jakarta projects?


look in mail you got when subscribing to list. Alternatively relevent text
is below.

--- Administrative commands for the ant-dev list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   <an...@jakarta-apache.org>

To remove your address from the list, send a message to:
   <an...@jakarta-apache.org>

Send mail to the following for info and FAQ for this list:
   <an...@jakarta-apache.org>
   <an...@jakarta-apache.org>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <an...@jakarta-apache.org>

To get an index with subject and author for messages 123-456 , mail:
   <an...@jakarta-apache.org>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send an empty message to:
   <an...@jakarta-apache.org>

The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "john@host.domain", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<an...@jakarta.apache.org>

To stop subscription for this address, mail:
<an...@jakarta.apache.org>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
ant-dev-owner@jakarta.apache.org. Please be patient, my owner is a
lot slower than I am ;-)

Cheers,

Pete

*------------------------------------------------------*
| "Nearly all men can stand adversity, but if you want |
| to test a man's character, give him power."          |
|       -Abraham Lincoln                               |
*------------------------------------------------------*