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-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
