James Duncan Davidson, the creator of Ant, has written about the very beginnings of the project. This history lesson shows us how Ant started out with properties files, and grew to XML... and how in many ways he wished it hadn't.

In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped for. As well, when you mix XML and the interesting reflection based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment which gives you quite a bit of power and flexibility of a scripting language—but with a whole lot of headache in trying to express that flexibility with angle brackets.

Read James Duncan Davidson in Ant and XML Build Files

Microsoft's new MSBuild utility will use an XML file format:

http://www.iseran.com/Steve/blog/archives/000029.html

http://www.gotdotnet.com/team/PDC/4075/TLS347.zip

Looks like Ant is just a copy of MSBuild.

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

Looks like Ant is just a copy of MSBuild

Just like Java is a rip off C#...

Dude, c'mon, ENIAC is obviously a rip off of the JVM.

just like java is a cript of c++... and on and on.

peace,

-M

wake up and smell the coffee.

JMV is a rip off of UCSD-p system from > 10 years back.

Read it here.

Chameleon: JMV is a rip off of UCSD-p system from > 10 years back.

Yup, and the UCSD-p system is a straight rip of the Turing Machine.

That took balls to take that one and not acknowledge it ;-)

Peace,

Cameron Purdy
Tangosol, Inc.
Coherence: Clustered JCache for Grid Computing!

What about poor old Charlie Babbages Difference Engine????

although changing the file format from XML to some sort of script language might "make" sense.

While I agree that build scripts can get out of hand quickly, I don't agree that this is amplified by the use of xml. This is the fault of some strategically placed documentation with ill advice, and lack of planning on behalf of whomever create the script.

In perusing the documentation available for ant, I've noticed advice about global targets and calls to other scripts which make maintenance a nightmare. The focus seems to be on getting the project build where half the thought should be given to future changes. Stop considering the overall organization of the script and you will pay for it later.

You can create a generic script which tackles the various types of Java deployments- application, applet, webstart app, war, ejb, ear, sar, etc - and allows the incorporation of other build facilities such as torque, without things getting out of hand and without restricting yourself. It's slower than slapping a build.xml file together and letting it evolve without regard, but much more enjoyable to work with and faster in the long run.

Here are some basic ideas:

1) Break the script into logical files using XML entity imports.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE project [
  <!ENTITY general SYSTEM "file:../../Build/general.xml">
  <!ENTITY library SYSTEM "file:../../Build/library.xml">
  <!ENTITY cvs SYSTEM "file:../../Build/cvs.xml">
  <!ENTITY j2ee SYSTEM "file:../../Build/j2ee.xml">
  <!ENTITY format SYSTEM "file:../../Build/format.xml">
  <!ENTITY servers SYSTEM "file:../../Build/servers.xml">
  <!ENTITY testing SYSTEM "file:../../Build/testing.xml">
  <!ENTITY xml SYSTEM "file:../../Build/xml.xml">
  <!ENTITY application SYSTEM "file:../../Build/application.xml"> ]>

<!--======================================================================
Main build targets and project specific information.
=======================================================================-->
<project basedir=".." default="nightly" name="ProjectName">

   <!-- ==================================================================
   What to deploy when we say deploy
   ====================================================================-->
   <target name="deploy.all" depends="deploy.ear, deploy.test">
   </target>

  &general;
  &library;
  &cvs;
  &j2ee;
  &format;
  &metrics;
  &servers;
  &testing;
  &xml;
  &application;

</project>

Each referenced file keeps targets, taskdefs, and classpaths that directly relate to the file - e.g., the compile.ejb target is in j2ee.xml.

2) make an accompanying .properties file for each .xml file. Have the .xml import the .properties, and keep your key names consistent.

3) Keep your project specific files in a separate location from the generic build scripts. This include files which contain classpaths for each type of compile, settings for filters, names of ftp servers to post reports to, etc. If you believe the generic script sections will get used elsewhere and prepare for it, it will happen and other people will get it when you explain the intent.

Since I've started this effort, I've never used another script on development efforts I've worked on. All of my changes to accomodate the new project have stayed within a file called localproject.properties for my development and project.properties for the nightly builds.

So James might have seen some cases where the build became quite a mess, but it's no more the fault of the his choice of xml than a messy playroom is the fault of a particular type of plastic. Kid's are just messy.

The problem is big complex configuration files are just big
and complex. The format isn't going to make any significant
difference past a certain point of complexity. You really
need a GUI to manage a complex configuration. Simple things
are fine in an editor. Write the same thing in properties
or s expressions. Still horribly complex to a poor
person armed only with a text editor.

You reallyneed a GUI to manage a complex configuration. Simple thingsare fine in an editor.

FireAntz, provides a visual interface for displaying and executing Ant buildfiles and their dependencies. I have not tried it yet though. See http://dev.eclipse.org/viewcvs/indextech.cgi/%7Echeckout%7E/ecesis-home/resourceLibrary/downloads/iceContest/iceContestWinners.html.

Boy is he right. I'm starting to get disgusted by XML already because it is used so much everywhere -- whether it fits the purpose or not. I'm glad I'm not alone to ask "Why?". Some things that never made sense to me:


- XML databases. I don't know why I'd store my data in such an inefficient way.

- XML to "program" something. Just think of the syntactical overhead of a loop or a conditional, in comparison to a foreach loop or an "if" in real programming languges. Tedious.

- parts of the same software system, all from he same vendor, communicate in XML. Hello?!

- XML config files instead of "*.properties", with a few dozens of options

- an amusing one: transforming database data to an XML format, then with XSLT to another, with the info finally winding up in HTML. Sheesh.

Most of these examples taken from our current project! Long live efficiency...


To me, the sensible advantages of XML are (1) it can be a good common communication format BETWEEN different software vendors or platforms, and (2) when (and only when) it must be externally represented, like the XML hierarchical diagrams in XMLSpy. But these are like UFOs to me, never actually seen XML used for these purposes. I know, I haven't been in the business as long as some others :-)

YMMV. I'd actually be happy to read a good use case!

Regards.

XML is easy to parse with "standard" parsers, I think it made XML popular for scripting, but probably it is better to learn to code parsers than to use XML for evrything (biuld scripts is not an exception too).

<<a href="http://www.martinfowler.com/bliki/BuildLanguage.html" target="_blank">http://www.martinfowler.com/bliki/BuildLanguage.html</a>>Martin Fowler</a> shares some similar thoughts in his blog.

LOL

Oops. Let me try this again...

Martin Fowler shares some similar thoughts in his blog:

http://www.martinfowler.com/bliki/BuildLanguage.html

http://rake.rubyforge.org/ (Ruby)

http://www.scons.org/ (Python)

The one thing that continually strikes me about the java open source tools space is how many of these products are launched without a competent GUI.

In fact I've met a number of otherwise reasonable authorities who suggest that it's somehow "un-manly" to use a GUI wrapper, or that it's "not for real programmers".

Such views are perverse for a couple of reasons.

A capable GUI wrapper can complement the underlying tool by exposing its power through masking the implementation complexities. This leaves the developer to concentrate on solving the business/process problem rather than worrying about a particular syntax. With a strong GUI shell who cares whether its XML or whatever?!?

It can substantilly improve productivity. A competent GUI allows the job to be completed quicker, reduces the skill threshold, and allows problems to be spotted sooner. With the current trend of moving jobs offshore this point should be on everybodies agenda!

I think there are times when a GUI is faster and times when a config file is faster. Once you cross a certain complexity threshold, GUIs actually slow down the process of working with things. If that weren't the case, WYSIWYG builders for applications would be a lot more useful than they are today. I think there is a place for a GUI when first learning to work with a particular kind of system (e.g, Java Swing programming), but once you understand what's going on, a GUI just gets in the way. Not in all cases, but in a lot. Also, I think that the reason a lot of open source projects don't have GUIs is because a good GUI is hard to write. I'd prefer, for example, that Hibernate concentrate on its core functionality than spend resources perfecting a GUI that might or might not see use.

I think personally that there's a place for both. Just as in the OS world, I prefer a combination of command line and GUI control, I prefer a combination of direct coding and GUI control. A GUI is great for helping to manage complexity, but if something can't be done outside of a GUI, there are severe limitations. Consider, for example, trying to manage a website using just notepad. You'd be foolish, because you need something like an IDE to manage complexity. Consider also trying to edit an HTML file to change a style. You could open it up in a text editor and make the change really quickly with a search and replace, or you could go into the GUI and find a properties window somewhere for each instance of a control that you want to change the style on. There's a strong case for both.

I certainly don't think that a GUI alone can do everything, and when dealing with things like deployment configurations, I think GUIs can just get in the way.

I agree with Drew. There is time and place for GUI tools and for plain text editing. There are times when you need a convenient GUI – e.g. to quickly write, validate or transform a large XML document with some XML editor, or analyze java structure of the project with SA4J. At the same time it is often advantageous to be able to edit the same source file (especially XML-based) with a plain text editor. Having no choice but to use the vendor-given GUI per task is not a good thing. Back to Ant, I find Intellij and Jbuilder support of Ant quite good.

About the article:
I always missed some sort of scripting language in Ant for control flow. It’s not needed in 90% of cases, but would really help in those rare but crutial 10%. Still, if such scripting language had been available, I think, we would have seen it abused not less as XML is.

Kris Bravo: This is the fault of some strategically placed documentation with ill advice...
:-) The Ant Developer Handbook (Sams) and the Java Development with Ant (Manning) suggest, for example, different approaches to <antcall> task. The former recommend using it instead of “depends” because it facilitates modularization, the latter says that it’s better to let Ant figure out the target dependencies by providing the “depends” info. Well, we have room for experiment :)

When I was learning Ant I felt that XML is a little bit cumbersome and not very appropriate for Ant files.

I talked with a few people about that impression and started a thread about this topic in a forum. But many people didn't share my opinion in this respect.

So I am very happy that the creator of Ant wrote that XML was not the best choice at that time!

There are not many people who are self-critical. Respect!

How can you debug an Ant file? As soon as someone asks himself this question, he can easily recognize that XML is not the best format for Ant files. Just my opinion.

It seems I continually find myself on the wrong side of fashion.... :-(

I was having this same discussion the other day with someone (check out his fish!). I think Ant - and even Jelly are a good compromise for build systems.

Why?

Because its mostly declarative - not programmatic.

Consider:

<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>

Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.

I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy.

Where ant starts to fall apart is when you want to do a load of conditional or iteration or more programmatic tasks. At that point, you want to write your own tags - and defer to a proper programming language. I dont thinke enough people do this. I dont know why.

The other place where Ant falls apart (referred to in the article) is when you have a large project - or many subprojects. The verbosity of Ant (and monotonous repetition of tasks) makes it a sea of text that, regardless of the angle-brackets, would make it difficult to read. (anyone tried reading a 6000-line java file?)

Here, Maven and Centipede have tried to address this by factoring out common tasks. With the Maven project.xml, you are back to a purely declarative approach that is very readable and maintainable...

-Nick

First I'd like to say:

OMG! So I'm not the only one who's been extremely annoyed by Ant XML config files. I actually suggested to one of my team mates, a couple of weeks ago, that we develop a custom domain-specific language (DSL) for Ant, because the config files were such a PITA. Moving along...

Consider:

<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>

Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.

I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy.

I think the reason you see this as readable, is because element attributes are named. If the Ant DSL had named parameters (like many other languages - for example, Smalltalk), this would be just as readable:

copy( file="bongo.jar", todir="bollocks/lib", overwrite="true" );

And with a DSL, people could easily provide their own higher level abstractions complete with control flow if necessary.

God bless,
-Toby Reyelts

Because its mostly declarative - not programmatic.Consider:<copy file="bongo.jar" todir="bollocks/lib" overwrite="false"/>Looking past the (often exaggerated) angle-brackets aspect of readability, it is very clear what this is going to do - even if you have never seen Ant before. It is very brief and very unambigious.I would be keen to see suggestions on how this could be done clearer in Python or Ruby. Or even Groovy.

You need to see the big picture, not just a single example.

In most cases targets are called from another targets with "depends". This is not declarative for me, but programmatic. int a = 0 is also declarative for you? Is this an argument that Java should better use XML? There are many other programmatic features of Ant build files.

How do you want to debug a Ant script? If Ant build scripts were written in Java, this would be possible. It would also be possible to detect many bugs at compile time and not later at runtime. How do you want to write a productive JUnit test for your Ant scripts?

When someone learns Ant, he has to learn that pseudo Ant script which is hidden in a declarative XML format. In order to write build files one must learn the declarative and programmatic aspects of Ant. Its in no practical case enough to learn only the declarative part of Ant.

For example XHTML is very good for its purpose because its 99% declarative. Programmatic things are done with JavaScript. There is a clean separation: XHTML for the declarative things, JavaScript for the programmatic. Now try to separate that in Ant build files! Would not make sense. If it is such a mixture, then it is a sign that XML is not such a good choice for it.

Of course XML has the advantage that someone must not learn a programming script in order to use it. On the other side, he must learn the programmatic part of Ant, which decreases this advantage a little bit. But I doubt that this advantage is practical. I believe that 99% of the people who use Ant are programmers. Maybe only 1% of the Ant script writers are system administrators with no programming knowledge. So even if it is an advantage in this respect, its only an advantage to 1% of the Ant users.

1. It's clear that if/else and try/finally constructs being written imply Ant has stepped over the line from good design to copying language constructs. However, I don't know if this implies that using a scripting language is that natural evolution. It might just mean that more needs to be done in task classes and not in build XML, or just better designed build files.

2. I don't see how tasks dependencies are better defined programmatically rather than declaratively. Doing it programmatically requires writing code that executes the tasks in order based on dependency. Do you really care what order they get executed, as long as tasks A & B get done before F? If I were to do this in scripting form, many of my targets would be methods and depends would become metadata of the method.

If Ant build scripts were written in Java, this would be possible

And how would you build the build scripts? :-)

This is not declarative for me

I agree with you that ant scripts are not 100% declarative. I guess that is why they are called "scripts" - and I guess thats why also I said they are mostly declarative. Even "depends" is mainly declarative.

You need to see the big picture, not just a single example

Apart from being a little condescending here, you have a point. At the individual task level, ant is mostly declarative. However, unless you follow some build-script styles to avoid it, the relationship between the tasks that make up a project build is lost in the details of the task implementation.

However, as I pointed out, this is not really to do with XML per se - but a lack of abstraction.

Projects sich as Maven and Centipede seek to get a higher level of abstraction - where you have a seperation between the project build and the individual task implementation. You can do the same with ant by yourself if you follow some rules.
a) Dont use "depends" for any of your target definitions.
b) Instead, write higher-level targets that wire the lower level tasks together.

There are a number of advantages to this:
Not using "depends" makes your scripts much easier to debug.
Not hard-coding your dependancies into the individual targets makes your build script more flexible - as the dependancies you want for development are very different to thos you want, say, for your overnight build - or even your cruisecontrol build.

-Nick

Incidentally there's an interesting discussion of how you can reuse those Ant tasks for declartive operations but use a real scripting language for procedural logic (and use regular method calling for describing dependencies) here...

http://lists.codehaus.org/pipermail/groovy-user/2004q1/000907.html

There's a test case here to show this kind of thing in action...

http://cvs.groovy.codehaus.org/viewcvs.cgi/groovy/groovy-core/src/test/groovy/util/AntTest.groovy?rev=HEAD&view=auto

James
Core Developers Network

for loops, if statements, try/catch/finally:

http://ant-contrib.sourceforge.net/tasks/index.html

:-)

How many developers use Ant's script task?

http://ant.apache.org/manual/OptionalTasks/script.html

http://stefanbodewig.blogger.de/stories/87512/

http://www.iseran.com/Steve/blog/archives/000103.html

Ant scripting with Groovy
http://groovy.codehaus.org/ant.html

BeanShell
http://www.beanshell.org/

Ruby
http://www.ruby-lang.org/en/
http://rake.rubyforge.org/

Jelly
http://jakarta.apache.org/commons/jelly/

Jython
http://www.jython.org/

Can anybody please tell me how to run a command from ant.

I need to run the following command:

jad -r [-d<directory_for_sources>] [<other_options>] <directory_with_classes>**/*.class

Thanks