ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [VOTE] Ant2 codebase adoption process
Date Mon, 28 Jan 2002 09:48:16 GMT
On Fri, 25 Jan 2002, <> wrote:
> On 25 Jan 2002, Stefan Bodewig wrote:
>> We'll remove some tasks or attributes that have been deprecated in
>> Ant 1.x and change the default values for some other attributes
>> where we feel the default is wrong (<ant> and inheritall).
> That's where I have problems. Why remove

We want to make Ant more consistent - using the same attribute names
for things that mean the same things - thus making it easier to learn
new tasks.

What we do ATM is to slowly move the tasks to a consistent naming
schema and deprecate the stuff we don't want to keep around.  Without
deprecation people would never learn that the preferred attribute name
for a given task has changed.

And then there will be a tool to autoconvert your build files ...

> and what do you mean by 'we feel' ???  Everybody feels a lot in html
> is bad - that doesn't make w3c to remove tags/attributes.

I cannot find <font> in XHTML 1.1 ;-)

> I don't think our current feelings/taste on how to name an attribute
> can have priority over preserving backward compatibility.

I agree, as long as we are inside the same release branch.

> Especially looking at recent history, where a large amount of pain
> was introduced for absolutely unjustified attribute name
> deprecation.

Could you please expand?

> I want tomcat ( for example ) to be able to build for people using
> ant1.3 or ant1.4

should be possible without any problems.

> or ant2.0 or any other version

You don't expect that the configuration file you've written for Tomcat
3.2 works without any changes in Tomcat 4.0, do you?

You should consider Ant2 to be a completely different product.  Ant
1.x will still be around and maintained.

> You can write a makefile that works with any version of make

Even with ancient versions?  I think the comparison is not fair as
make has had time to abandon old cruft.  Ant still is less than two
years old, if you just count released versions.

>> Dereferencing properties that have not been set is one thing, a lot
>> of build files today rely on Ant printing ${foo} if foo has not
>> been set, while we have agreed to throw an exception here in Ant2.
> I do rely on that feature - and is a perfect example of what I'm
> talking about !

Please explain why you rely on that feature.

Most projects that use it do something like

<echo>$${junit.jar} is ${junit.jar}</echo>
<echo>if you see $${junit.jar} instead of a real value, this means
you've forgotten to set the property $${junit.jar}.</echo>

Given the way property precedence works, wouldn't

<property name="junit.jar" value="not defined" />
<echo>$${junit.jar} is ${junit.jar}</echo>

be cleaner and easier to understand by the user as well?

>> The unification of properties and data-types is another thing that
>> can lead to problems that are difficult to catch automatically.
> Then leave them alone and create a new type of ant2Property that
> does what you want. The current properties will continue to work,
> everyone can be happy.

Except those who will have to maintain different "types" of properties
in a single code base and explain to new users when to use which ...


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message