On 2/16/2012 2:36 PM, Nicolas Lalevée wrote:
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.
No, you are right that these companies need a good reason to upgrade. What I am saying is that the pain that is caused by trying to make minor modifications to large complicated build systems, combined with having multiple large build systems that do very different things and the difficulty in dealing with these major changes in operating, is the thing that can cause at least some of them to dedicate the resources to standardize on something simpler. But I haven't found any that are interested in considering a new build system. They know Ant. Any upgrades they want to do in their own time. That is why I think backward compatibility is so important. They can roll out an upgrade to Ant 2, make sure everything works as expected, and then in their own time roll out a simplified, standardized build to each of the systems they are currently running 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)
I've got a lot of customers with the kinds of Ant build systems I am talking about. Precisely zero of them use anything other than an XML format for the build. Downloading extra bits to do funky things is not in their DNA. Some of them are forbidden to use Ant Contrib because it hasn't been through a security audit.
I used to think we are living in a Maven world and that Ant was fine being just in maintenance mode. Since I've been helping these customers integrate my product with their systems, including their build systems, I've come to realize that there is still a very strong need for Ant out there, and that they are hurting from the complexity of it. Some of the complexity is from build systems that were written pre-macrodef and they haven't seen that one feature as compelling enough to commit to a rewrite. Some use macros, though, and things are still pretty complicated.
I think this is Ant's market: places that don't want the dependency features of Maven and require complete control over exactly how their build is done. A lot of companies have their own, internally written build file generators just so their build systems are consistent and exactly what they want. Our Related Projects and External Tools page has some of these that were made public, I suspect.
Surely there is a better way than requiring users of Ant to write generators to deal with the complexity and keep it customized.
--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
