You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Nico Seessle <ni...@seessle.de> on 2000/09/16 19:48:01 UTC

Inconsistencies?

While reading some source I found the following inconsistencies (as I
think).

1. Property uses (if specified) all three ways of defining a property; in
the ant-task in reInit (seems to be used if ant is executed twice) the
behaviour is different - it uses the first of name/value, file,property if
they are specified all. Which behaviour is correct?

2. Conversion from String to boolean is done in severeal places (and in
different ways).
3.1 Should all occurences be changed to use Project.toBoolean()?
3.2 Should the behaviour of Project.toBoolean be changed so that it accepts
uppercase/lowercase/mixedcase and string with leading/trainling spaces?

Other occurences use for example
Javac:emacsProperty.equalsIgnoreCase;Delete:"true".equalsIgnoreCase(verbose.
trim().

If only 3.1 is done this may break build-files in some cases.?

What do you think about these?

Nico



Re: Inconsistencies?

Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "NS" == Nico Seessle <ni...@seessle.de> writes:

 NS> 1. Property uses (if specified) all three ways of defining a
 NS> property; in the ant-task in reInit (seems to be used if ant is
 NS> executed twice) the behaviour is different

Yes, going to remove to "else"s 8^).

 NS> 2. Conversion from String to boolean is done in severeal places
 NS> (and in different ways).

For historical reasons. I think the places that don't use
Project.toBoolean have been there first. Then Project.toBoolean was
invented and most new tasks used it. When IntrospectionHelper got into
the game, Project.toBoolean became obsolete in most cases - as you can
now have a setXXX(boolean vale) attribute setter that will invoke
Project.toBoolean behind the scenes.

To really make all tasks consistent, all setters that convert their
argument to booleans themselves should take a boolean argument
instead. Same holds true for all setters that convert from String to
File BTW.

All remaining cases should be converted to use Project.toBoolean
instead.

This is a "should" not a "must". The general approach I've taken so
far is to convert the tasks that I need to touch anyway and don't
change those I had no other reason to tinker.

Do others feel a major cleanup step would be needed?

Stefan