ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Tue, 14 Feb 2012 19:02:41 GMT
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:
For additional commands, e-mail:

View raw message