Ant Now A Top Level Apache Project

hardcorejon writes "Am I the only person who didn't notice that on November 18th 2002, the Apache Ant Project had migrated out from under the Jakarta Project umbrella to become a top-level Apache project, joining the ranks of the Apache HTTP Server Project? Well, for those of us who use Ant on a regular basis, this is great news. Ant is an incredibly powerful tool, increasingly a standard build system for many new projects."

Comments

What is Apache Ant?

[fulldecent]

What is Apache Ant? Ant is a Java-based build tool. In theory, it is kind of like Make, without Make's wrinkles and with the full portability of pure Java code.

info about ant

Re:What is Apache Ant?

[Anonymous Coward]

Make also requires shell. Ant doesn't. That's the reason they give for Ant being more portable.

Re:What is Apache Ant?

[bay43270]

As opposed to make, which is written in C, which only runs on a few platforms?

You can't even copy a file in make without knowing what kind of system your on. Take a look at the targets available in ant some time. Its built to remove the need to access the operating system (as opposed to make, which offers dependency checking and little else.

I'm not trying to fault make... it simply wasn't built to be cross-platform. But lets not pretend that being available on many platforms and allowing cross-platform code are even close to the same thing.

Re:What is Apache Ant?

[Ouroboro]

...But portability is not an advantage it [ant] has over make.

Actually it is. The reason for this is that make (and it's derivatives) relies upon shell commands to extend it's functionality. These shell commands cause the make file to be incompatible to any platform where that shell is not installed. Ant on the other hand can be extended via java, so these extensions are compatible with any other platform that runs the jvm. If make offered some sort of ability to dynamicly add functionality in a platform neutral way, then make would be as portable as ant.

Re:Alternatives to ant and autoconf et al?

[rplacd]

Some alternatives to ant/make are

• cook (probably the best contender),
• Mk (which is like bitkeeper+make),
• Jam,
• cake (does anyone use this any more?), and
• the Plan 9 mk.

There's also something called Cons, but it needs perl to work. See this.

I haven't found a good alternative to autoconf yet. There used to be Metaconfig, but I don't know who maintains it any more (or where). It produces configure scripts similar to what you see when you configure perl. This guy uses some unreleased software package for his build systems that tend to work really well -- for C code under Unix.

Come to think of it, if someone ports/writes a build tool in C#, you'd be set.

Re:Alternatives to ant and autoconf et al?

[Anonymous Coward]

NAnt is a .Net version of Ant. Been around for about a year now I think:

http://nant.sourceforge.net/

For Java, Ant is one of the few options. You cannot be sure perl/make etc are installed on a user's platform, but if they're grabbing Java code, they have Java.

Re:And makes too many assumptions.

[msuzio]

Hmm... I think you dropped Ant too quickly. It certainly doesn't require separate build and source directories. I use it for all our projects here (well, OK, so that's 2 official projects and maybe 3-4 'toy' projects I'm personally working on), and in all instances, I have .java and .class files in the same directory.
You can have a very minimal build.xml that does this, and automates things like JAR builds. For a project where you're already using Java, I wouldn't use anything else. It even plugs into most Java IDEs, if you're the sort who uses those
silly things ;-)

Re:And makes too many assumptions.

[s88]

Re 1: uh ok, and src/ to the jar
Re 2: uh ok, add src/ to the runtime classpath
Re 3: uh ok, see Re 1.
Re 0: you can, in fact, put your build and source in the same dir.

Re spellcheck:
Ant is not, as a core distribution, everything and the kitchen sink... it is an, arguably, minimal set of tools required for a meaningful build process. However, ant is completely modular and there are hundreds of articles describing how to add custom tasks to it. It was designed with this clearly in mind. If you have a spellchecker in mind you can build a new task in 20 mins and use it in your next build, or just exec it.

You, sir, make too many assumptions.

Scott

Re:Alternatives to ant and autoconf et al?

[steve_l]

Actually Ant does C++ code quite nicely via the task from ant-contrib.sf.net. This task is biased towards the gcc chain, but works with many others

One nice thing does is dependency check based on header file inclusion info, and your compiler settings. So you dont need to state dependencies, the task works it out for your. slick.

Re:And makes too many assumptions.

[steve_l]

Well, maybe we do try and dictate a bit. We often get bugreps by people complaining ant is rebuilding stuff all the time, which we explain is because you need to put files in a directory structure that matches the package tree, which makes them complain we are control freaks or something. Which forces us to point out the bits in the java spec that says you must lay out your files in this order for javac to import stuff automatically. Similarly, we get sporadic complaints about how we do JAR manifest line wrapping, which are in fact exactly how the language specs demand it, even if one or two duff apps out there cant handle it.

But if we werent strict control freaks, who would be?

As for redisting source in your OSS project, yes, that is trivial; everything does it, just multiple s.

You say the benefit of giving everyone the source is that they can modify it. I agree, but also, what if you want the recipients to build it, That is where ant is great; anyone on PC, Mac, Linux, AS/400, Netware, ... can take your build file and build a big complex app then run the unit tests against it. And that no-brain-rebuild is a good reason to provide an ant build file, even if you stick to make or worse, an IDE.

-steve

(ant developer, co-author of Java Development with Ant,...)

Not Only Ant...

[jaaron]

Several Jakarta Subprojects are becoming top level projects:

db.apache.org (OJB and Torque)

avalon.apache.org (The Avalon server framework).

Plus Tapestry is moving into Jakarta. If you look around there really is a lot going on over at Apache, especially within the Jakarta projects.