On 25 Jan 2002, Stefan Bodewig wrote:
> On Thu, 24 Jan 2002, <[EMAIL PROTECTED]> wrote:
>
> > But my point was that no change or feature in ant2 justfiy braking
> > backward compatibility at:
> > - build.xml level
>
> Most discussion we've had so far would add things to build.xml but not
> render old build files invalid.
Adding new stuff is perfectly fine - and I see no problem adding it in
ant1.x ( like many other things were added in ant1.x - types, paths, etc ).
> 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). These things can
> easily be fixed with a conversion tool (be it an XSLT stylsheet or
> something else).
That's where I have problems. Why remove 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 don't think our current feelings/taste on how to name an attribute can
have priority over preserving backward compatibility. Especially looking
at recent history, where a large amount of pain was introduced for
absolutely unjustified attribute name deprecation.
I want tomcat ( for example ) to be able to build for people using ant1.3
or ant1.4 or ant2.0 or any other version - I hate requiring a
specific version of ant. Maybe people use other projects with a different
version of ant. You can write a makefile that works with any version of
make ( not easy, but possible :-), but I can't fix tomcat's build.xml to
work with both ant1.3 and ant1.4 without warnings ( ant1.2 - don't even
think about it ). All this in what's supposed to be the 'stable' ant,
where people at least are trying to keep backward compatibility.
> Other things may be more difficult to catch in an automated way.
> 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. We should
> start printing warnings in Ant 1.x and tell people to assign default
> values, but this is a point where old build files won't work with
> Ant2.
Or you can add an attribute 'throwExceptionsOnUnsetProperties" in
build.xml or some similar mechanism.
I do rely on that feature - and is a perfect example of what I'm talking
about !
Yes, people wanting exceptions to be thrown will have to set an attribute,
and the code will have an extra 'if' in it. But thousands of projects will
not have to change just because we have a different taste on what the
behavior should be.
> 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.
Even things like modifiable vars can be added easily - by using an
alternative syntax for example for the new props ( instead of ${} ).
The old stuff will continue to work fine.
> > I'm very worried that ant2 will 'backdoor' this kind of stuff by
> > changing the codebase as a 'package' - without people beeing able to
> > analyze each individual change and decide if it's worth it.
>
> Costin, please see <http://jakarta.apache.org/ant/ant2/features.html>,
> this is a list of features the committers have agreed on, feature by
> feature. I'd expect Ant2 to largely follow what is in there, no
> matter which codebase will emerge for it.
The list of features is fine - how they are implemented is a different
issue. For most of them it is possible to do an implementation that
preserves backward compatibility and minimizes the pain, or an
implementation that just doesn't care about everyone else.
I would like a vote on each feature _implementation_, not on a package.
Everyone agrees that features is good to have, there are multiple
ways to implement it ( in the different codebases ), we should select
the best implementation for it.
It seems everyone agrees with introducing some incompatibilities in
build.xml - and that's fine, we lived through incompatibilites in ant1,
but that doesn't mean we shouldn't analyze each individual change.
Some features on the 'wish list' may not be implemented in ant2 -
that's allways a difference between 'goals' and 'reality'.
> There are some other features we seem to agree upon that haven't made
> it to that list (yet), something like "it should be possible to define
> a new condition without changing the Ant's source code", reiterate
> "condition" with "file selector" or "EJB container specific tag in
> ejbjar" or ...
Any feature on you put on the list is fine with me - but if the
implementation of that feature is breaking something else ( especially
existing features ) - it should wait until a better solution is found.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
