ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <br...@callenish.com>
Subject Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Date Thu, 16 Feb 2012 19:47:05 GMT
I'd hope to go further than that in backwards compatibility. I work with 
a lot of companies that are:

     a) resistant to learning new things unless there is a good reason 
for it (such as the migration from Apache HTTP Server from 1.x to 2.x to 
resolve security issues)

     b) have a number of separate Ant build scripts that follow 
different standards in different areas of the company, particularly if 
they have

and c) need to have a justification to allocate resources to upgrade and 
change a working build to use new features, which standardizing builds 
across the organization using new features in a major release that 
simplify the build system may offer them.

You are right about the plugin parser architecture in Ant 1.x, but one 
of the problems with it is that there is nothing shipped by default. 
What I meant was that I would love it if Ant 2 also represented a point 
where new builds could think about using a new build format 
automatically, just based on file extension or a flag on the command 
line. That might encourage new projects to adopt it.

On 2/16/2012 10:57 AM, Nicolas Lalevée wrote:
> Le 14 févr. 2012 à 20:02, Bruce Atherton a écrit :
>
>> 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.
> A simple trick can be a declaration of a "version" attribute which would declare the
minimum Ant version required to run the build file, and also declare how it should be interpreted.
This is how it works for the ivy.xml for instance.
>
>> 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 think you can already today, there are some experiments which show it works [1] [2].
The names of the classes of Ant may not be explicit, but I think the abstraction is there.
>
> Nicolas
>
> [1] http://svn.apache.org/repos/asf/ant/sandbox/javafront/
> [2] http://svn.apache.org/repos/asf/ant/sandbox/groovyfront/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message