On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
This will lead us to the discussion of what Ant2 would be. A rewritten
Ant that remains compatible (or mostly so) on the build file level or
something quite different?
My opinion.
I think we need at least an option for being backwards compatible at the
build file level and it should be the default for quite a while after an
initial 2.0 release. I'd hope, though, that a redesign would have a
fully pluggable parser so that even with the first release there was an
option to use something other than XML.
I actually think build file compatibility should be a feature of the
first alpha. Here is how I thought it might be achieved using the change
in namespace that would allow Ant1 and Ant2 to coexist:
Phase 1: Ant 2 handles a tag if it knows how, otherwise passes it to Ant
1. Originally all the infrastructure would call Ant 1 but that would
gradually change as more facilities were developed for Ant 2.
Phase 2: Ant 2 can do most things, but there are a few concepts and tags
that are foreign to it that it needs to pass to Ant 1. Ant 1 comes with
Ant 2 but only in the bootstrap form.
Phase 3: Ant 2 can emulate enough of Ant 1 that it isn't necessary to
ship it, but it is an option for those who want to run in compatibility
mode or use an <ant-one> tag or similar.
Basically I am talking about an aggressive refactoring with no thought
to backwards API compatibility. That compatibility has tied our hands
from doing a real refactoring for a decade.
I agree with you that our tasks are fully debugged. They should be
reused as much as possible. I would imagine that as far as tasks were
concerned, a simple massaging before moving them to a new package would
be all that was required, to take away cruft and to use a new style for
defining tasks. And to move calls to the infrastructure over to the new one.
What I started to implement was to make everything that is visible in a
build file an immutable property, tasks and selectors and conditions,
everything. They would all be POJOs with annotations to indicate how
they are exposed to the dependency tree. The annotations would be a
dependency on Ant that may not be desirable or possible for legacy
classes, so a base proxy class could be extended to provide the
annotations and automatically call into a reference POJO for behaviour.
Creating a PropertyProxy from the POJOs to make them immutable could
likewise be done. Any @Modifiable method on the Task would simply not do
anything or throw an exception.
Making everything a property would have an effect on what "immutable"
means. It would mean that it was not the value of the property that was
immutable, but the behaviour. So calling <tstamp> would always set
TSTAMP to the current time, and the available task and condition would
return true or false depending on whether a file exists at this point in
the build. Given how dependencies are currently resolved I can't think
of a way this change would affect the ordering of the build. Of course
if you set the value to an Ant1 style property the value becomes
immutable, so backward compatibility would be maintained.
Some might not like this change. Personally, before macros I found far
too many "time1", "time2", "thisfileexists1" in my build files. After,
the fact I have to create macros to handle this basic functionality is
just an irritant. But it is an irritant I would love to see removed from
our lives.
Anyway, those are my thoughts on backward compatibility. I would love to
see more discussion about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
