Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit : > 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.
I don't know conclusion you're having there. Such companies shouldn't worry about any new major version, because they actually do want to stick with the old one for stability purpose. I guess that the companies which would be troubled is the ones which want to keep up with the releases, migrations from one version to another should not be too painful. > 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. Well, again, I think it's already there, no need to wait for an Ant 2.0 :) If you add the groovy-front.jar in Ant's boot classpath, write a build.groovy, then a launch of ant with no parameter on the command line will execute your groovy build script. See ProjectHelperRepository.getProjectHelperForBuildFile(Resource) Nicolas --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
