The Apache Ant team is proud to announce the availability of Ant 1.6. Ant 1.6.0 adds a lot of new features, most prominently support for XML namespaces as well as a new concept of Ant libraries that makes use of namespaces to avoid name clashes of custom tasks. It also supports macros, file imports, and ssh tasks (e.g. scp).

Ant 1.6 New Features

The Ant Home

Full 1.6 Release Notes

Finally We have simple way to import build files (i mean - compared to entity "import"). For me, lack of of "import" feature was the biggest disadvantage of ANT, compared to other build systems (even NAnt had it, AFAIK, not to mention make). I've worked on huge projects with lots of build files - which was extremally hard to maintain when it came to modify one task in 20 build files. Now it's past, and even more - powerfull macros and task templates. It seems ANT becomes as powerfull as make but just simple. Thanks guys!

Artur

It's nice to see the great work they have done with ant. I hope to use the new features soon.

As far as "imports" go, you can do them (not pretty, but it works)

e.g.

<?xml version="1.0"?>
<!DOCTYPE project [
    <!ENTITY classpath SYSTEM "file:../xmlinclude/classpath.xml">
]>

<!-- include the common classpath here -->
&classpath;

Another nail in Maven's coffin. Hooray for ant!

Hani -- I thought you liked Mavin? Especially after all those nice things you said for it. ;-)

Rob

Let me first state that I have used both Ant and Maven on various projects, so I'm very familiar with both tools. That said, why is everyone so anti-Maven? What's wrong with it?

The only thing I can see that bugs most people is that it is a bit more difficult to grasp than Ant. And, some people don't like letting Maven dictate project structure. Other than that, though...what's your gripe?

I actually have come to appreciate Maven's imposed structure (which, btw, can be changed by setting certain properties). The repository idea is fantastic. The 700+ predefined goals makes my build files so much simpler. The self-documentation and self-unit-testing is good. Never having to deal with classpath--priceless.

I'm not trying to bash Ant 1.6's release--I'm still an Ant fan--but I am just curious why people hate Maven so much.

Ant is release at a new version 1.6. So what about maven? When will it finish rc and release the final version? not far away I think.
Quite some IDE have support with ant, while almost none support maven(?). That is quite a problem I think.

There's nothing at all wrong with Maven ... it builds onto where Ant takes people. It adds to their capabilities. It isnt perfect, yet but it is only at about 1.0 release state so will only offer more in the future.

I wouldn't say that people are against Maven ... thats just Hani, he always has a gripe against humanity at some level or another.

I found this interesting (posted on the BileBlog http://www.jroller.com/page/fate/20031216#the_codehaus_of_crack)

I've actually used ant and maven quite a bit. I've been looking for a comparison of the two without too much bias. Hani seems to bile Maven but doesn't provide much insight. Here are some of my thoughts on the two.

* Why is Maven a separate project? Why isn't maven just a set of custom tasks for ant?

* Why do people think that Ant doesn't scale? I've built projects over 700KLOC with Ant without any complication. Trying to do something comparable with Maven would be hysterical from what I've seen.

Let's look at the history of Maven for a second. It originated in the Jakarta world (AFAIK). Jakarta projects are very similar in their build, jar, and deploy to website process. Some developer threw a hissy when he saw that the build files contained duplication between projects. Also, said developer also appeared to have a problem with multiple copies of the same jar on his machine (b/c we all know how valuable disk space is these days). Maven solves these problems but at the cost of simplicity and flexibility. I truly believe the maven project should simply be a set of custom tasks for Ant and a couple build templates. End of story.

The idea of a remote repository for versioned jars is convenient, but has nothing to do with Maven the build tool. Actually, the fact that Maven creates a central repository on your machine for jars actually becomes a huge pain in the ass b/c this makes it difficult to package projects for deployment with dependencies included. Also, in any build you have dependencies that exist at least on two levels (build and run). Maven makes no attempt to make this distinction.

Have you ever gone to download a Maven powered project? Maven projects are impossible to deal with because the build tool inexplicityly becomes your deployment and distribution tool. Not a good idea. A person downloading your project shouldn't give two shits about your build tool. They just want to click on a single link and have everything they need to run and integrate your project into theirs.

I officially give everyone permission to check jars into their SCM. Maven has promoted this idea that jars have to be kept in "repositories". Well.. every project I've every worked already has a repository that comes with version control and a whole host of features that make an http file server look a little childish. I thought everyone knew this but as a general rule - CHECK EVERYTHING INTO VERSION CONTROL (Yes everything).You will thank me later.

Maven is breaking the cardinal rule of development tools - DO ONE THING WELL. It manages to be a half -assed attempt at a lot of things: build tool, CMS, jar repository, dependency manager, deployment tool, release manager, etc.

At this point, Maven appears to be in a death spiral resulting from feature creep. It's death is imminent, and will be ugly.

While it's generally accepted not to check in any compilation unit, or anything else which can be derived from contents of the same repository, there is great value in storing compilation targets of other projects (jars) along with source code.

The specific logistics of this should be driven by the development process of the organization. How do you treat 3rd party jars compared to jars from other teams in your company (shared componentry etc.).

From the build tool's perspective, this should not matter. Unless it's built along with the rest of the project, Ant (or other build tool) shouldn't know or care where an outside .jar came from.

Ant has been successful for (at least) these reasons:

1) OS agnostic
2) J2EE platform agnostic ("insert your vendor's ejbc here" etc.)
3) it's SCM agnostic - CVS and others do have specific tasks, but it's not necessarily coupled
4) It was easier than it's predecessor (in most cases "make")
5) Easy to extend to solve related problems

I don't hate Maven or anything, but while I was able to grasp ant quickly, Maven proved to be a complete pain to just comprehend - let alone set up and use for a real project.

Just I have to write a script for the big project to build cleanly.
I have two options:nmake and ant.
using ant I could be able to do in no time.
but NMAKE????
thanks to Duncan Davidson...

I am sorry to see such an influential Java project get released with a poorly implemented import feature. One would think that by now it is common knowledge that a Java app should to allow usage of a URI as a pointer to a resource containing a file to be imported. Using the get task followed by the import task to solve this problem only adds unnecessary clutter to what might have been a one liner.

Build fails with the "No supported regular expression matcher found" message. All the required classes are there, on the classpath.

We do a ton of importing (the hard way). The fact that we don't have to hardcode paths seems wonderful. This will further legitimize Ant as an enterprise deployment tool.

BTW: I'd expect a lot more posts from TSS users on this.

There's a few nice features here. While none of them are a really fundamental shift in the way Ant works, taken together the offer a marked improvement in the ability to build complicated build scripts in Ant - particularly the import, macros and predefs. Not only will it be possible to build better, more complicated scripts, but it'll actually be more readable, by reducing the Ant artifacts around reusable sections of code.

And since I've already had to do external integration with both SSH and SCP, it's certainly nice to see these features.

All in all I'm quite pleased to see this release.