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 Thu, 16 Feb 2012 23:05:29 GMT

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:
For additional commands, e-mail:

View raw message