On Fri, 25 Jan 2002, <[EMAIL PROTECTED]> 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 ...
Stefan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
