<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252">
	<TITLE>Welcome to Apache Ant 1.6</TITLE>
</HEAD>
<BODY LANG="en-US" BGCOLOR="#ffffff" DIR="LTR">
<H1>Welcome to Apache Ant 1.6</H1>
<P><BR><BR>
</P>
<H2>Your life just got better. 
</H2>
<P>Not in big ways. Your social life isn't going to be helped, though
with any luck you may now have more time for one. Nor is it going to
take less time to write your Java code -although we note that running
<A HREF="http://xdoclet.sf.net/" TARGET="other">XDoclet</A> under Ant
lets you avoid writing so much code. Nor is a new release of Ant
likely to provide a fundamental kick-start to the currently somewhat
subdued technology and software industries. 
</P>
<P>No, Ant1.6 will not fundamentally change your life. But if you do
have to get software out on time -"roughly what you asked for,
roughly when you asked", then Ant1.6 provides lots of little
improvements over the existing version. 
</P>
<P>Before we look at those details, lets look at the world of The
Automated Build.</P>
<P>Firstly, we'd like to thank everyone for all those awards that
have been flowing in. The JavaWorld Editors' Choice Award for "Most
Useful Java Community-Developed Technology", The Java
Developer's Journal "Editors Choice Award", and Java Pro
Reader's Choice award for "Most Valuable Java Deployment
Technology." Wow. That's a lot of awards. Aardman Animations
keep all their Wallace and Gromit -related oscars in a cabinet in
their tea room. If the Apache organization had a tea room, those Ant
awards would be forcing all the other (excellent) Apache products to
fight hard for their cabinet space. 
</P>
<P>All those awards come for a reason: everyone, at least everyone
working on any project of moderate complexity, needs to control their
build process. Ant is one of the best ways to do it in Java, and,
over the past four years, it has moved from a tool used simply to
build Tomcat cross-platform, to a tool used across many open source
projects, and now to a tool used by almost all Java projects. Indeed,
pretty much the only competitor in the Java space is a sibling
project under the Apache banner, <A HREF="http://maven.apache.org/" TARGET="other">Maven</A>.
One of the obvious signs of Ant's success is that all the popular
IDEs, from the Open Source -Emacs JDE, Eclipse, NetBeans and jEdit -
to the commercial: IntelliJ IDEA, Borland JBuilder- all ship with
built in Ant support. This lets you use your favourite IDE for what
it is good at: editing text, creating Java source, refactoring
existing code, debugging and the like, and you can turn to Ant for
co-ordinating the build-test-deploy/deliver process. That Ant based
process can be triggered from keystrokes in the IDE, command line
invocations for those so inclined, and in automated scheduled builds
so the machines can keep an eye on the engineers. Another sign is how
Ant is helping the Java aisle of bookstores fight back against
attempts by books about Macromedia Flash to take over all the space
-there are now seven or eight books on the subject, with more on the
way. Germany and Korea have their own native language books too,
which shows how global the tool is -in use and in development terms. 
</P>
<P>The other metric of success is the pre-announcement hints from our
distant software colleagues in Redmond, Microsoft, of a new build
tool, "MSBuild", which "might be the single most
important feature innovation in our pipeline", according to one
MS developer. That is surely the greatest metric of success: XML
based build tools are now viewed as so essential to the modern build
process, that Microsoft has to come up with a competitor to Ant to
win Java developers over to .NET. Let's hope they discover we like
ubiquitous JUnit testing too, and refactoring IDEs that create and
run the tests for us. 
</P>
<P>Success comes at a price, of course. One price is all those
support calls. We try and stay on top of the bug reports, but one
thing we cannot do is fix inconsistencies or things that seem like
defects if they stand a significant chance of breaking existing
builds. Its sad, but there are lots of little minor faults with Ant
that we don't dare fix because, well, things might break. For
example, why don't if= and unless= clauses also support
<code>if="${property}"</code> clauses? Alternatively, why isn't it an
error to use a property that isn't defined. Everyone that has ever
seen directories called ${build.dir} popping up the source tree will
understand why that behaviour is not always what you want. Well, we
could fix these things, but we won't, because backwards compatibility
is sacred. 
</P>
<P>That is the other price of success: all those users who have
existing build files they want to work. And all those IDEs that host
Ant, and who want an easy upgrade to a new version. This means we
have lost a lot of the flexibility we used to have in the early days
of the project, when different versions of Ant could have completely
different property evaluation algorithms and nobody would bat an
eyelid. Now, even the most obscure bug fix ends up generating 'you
broke my build complaints'. 
</P>
<P>This explains why there will not be the 'incompatible upgrade'
version of Ant, Ant2.0, that has long been discussed on our web site.
</P>
<H2>Where is Ant2.0?</H2>
<P>For years we have been discussing Ant2.0, the complete rewrite
version that would be cleaner and faster, and slightly incompatible
with Ant1.x. It would be the opportunity to take the lessons from the
1.x line, and support them cleanly. We even got as far as having
multiple implementations of new Ant engines in the CVS repository,
especially Mutant and Myrmidion. But we always seemed to have a hard
time making progress -everyone was too busy using and firefighting
Ant1.x that nobody got time to work on the 2.x codebase. Which is a
shame, as all the proposals had interesting ideas.</P>
<P>After Ant1.5 shipped, the future of Ant effectively resolved into
one of evolution rather than revolution. There will be no Ant2.0 with
a complete new engine underneath. There will be no need to run XSL
transforms over existing build files to move them to the Ant2.0
world. Instead Ant1.x is getting better underneath the build file
-improving its internal design while retaining five-nines backwards
compatibility with existing build files. 
</P>
<P>And that is what we have been up to.</P>
<P>Under the hood, Ant1.6 contains some of the most major reworkings
of the core Ant system yet seen. We haven't finished yet, and are
holding back some of the more visible developments so we can see what
works before their release in a product forces us to maintain them.
But the underlying parts of Ant are now set up for the next stage in
development. 
</P>
<P>Whether we call the next version of Ant 1.7 or 2.0 is something we
have yet to decide. Maybe we should call it 3.0 just to surprise
people.</P>
<H2>What has changed</H2>
<P>Look at the <A HREF="WHATSNEW" TARGET="other">WHATSNEW</A>
document to get a full list of changes. Here are some of the core
conceptual differences.</P>
<H3>No more Java1.1</H3>
<P>We got fed up of jumping through reflection hoops to do everything
from weak references to setting file timestamps. After consultation
with the Ant user mail list, Ant1.6 only runs on Java1.2 or later. It
can still cross compile to Java1.1 if that is what you have to do. We
haven't completely purged all 1.1 references in the docs, or 1.1
support from the source, but that will come over time.</P>
<H3>New classloader use.</H3>
<P>This is going to make people nervous. If there is one thing Java
developers have learned over time, only the very naive, the very
brave, or the very competent do things with classloaders. We will let
the Ant users decide what category to put us in, but before everyone
panics, Costin, of Tomcat fame, did a lot of the work here. You don't
write application servers without understanding classloaders inside
and out. 
</P>
<P>The impact of these changes will trickle out over Ant versions. In
1.6, the key features are 
</P>
<OL>
	<LI><P>We have got rid of the bit in the batch file/shell script
	that built up a really big classpath environment variable from
	everything in ANT_HOME/lib. Now that is done in a launcher class
	that does the work then calls tools.ant.Main as before.</P>
	<LI><P>You can add new library directories to that classloader with
	the -lib option on the command line. This option is interpreted by
	the launcher class, so will not work with IDEs and other apps that
	use the inner entry point.</P>
	<LI><P>We have broken up optional.jar into many-many jar files, such
	as ant-commons-logging.jar, ant-xalan2.jar, etc etc, and a
	nodeps.jar for optional stuff without any dependencies. This creates
	a lot of jar files.</P>
	<LI><P>You can now &lt;taskdef&gt; existing tasks -like &lt;junit&gt;-
	by including the specific ant jar <I>and</I> the dependent libraries
	(i.e. junit.jar) in the declaration. This solves the problem of
	ANT_HOME/lib needing to contain every jar possibly needed by every
	user/project. You still have to declare the tasks one by one,
	something we will fix in Ant1.7</P>
</OL>
<H3>Adapters</H3>
<P>These are Java classes that <I>adapt</I>&gt; arbitrary Java
classes into ant tasks or types. There has always been some of this
stuff inside Ant, but now you can &lt;taskdef&gt; a task by naming
not just the implementation class, but the adapter class. An adapter
is essentially a meta task implementation -something that can be used
to create new tasks dynamically. Which, when you consider that the
core of Ant is fundamentally an XML to java mapping system and a
simple workflow engine, may let you do very unusual things with Ant. 
</P>
<H3>Antlib: Ant libraries</H3>
<P>This is something we will expand in future. Till now you could
declare tasks and types with &lt;taskdef&gt; and &lt;typedef&gt;. If
they were in a jar, you could write a properties file and name the
resource path of the file in the jar. If you wanted to have both
tasks and types, you had name a shared classloader. If you wanted to
add more things -such as conditions or mappers, you were out of luck.</P>
<P>Antlibs are Ant Libraries, JAR files containing the code to extend
Ant, and an XML description file to describe how Ant is extended.
Before anyone panics at 'yet another XML descriptor syntax' to learn:
you may already know the syntax. We call it "Ant build files".
Actually it is a subset: it can only contain those task declarations
that are derived from org.apache.tools.ant.taskdefs.AntlibDefinition.
That includes &lt;taskdef&gt; and &lt;typedef&gt;, and <I>any other
task you choose to derive. </I>We are experimenting with scripting
and some kind of task predefinition declarations in antlibs. With the
latter, you will be able to write a predefined task -such as a
&lt;javac&gt; derivative with the compiler options set, and then use
it any of your build files. This is all too experimental to get into
Ant1.6 -expect it in the successor. For now, start using antlibs and
use the &lt;taskdef&gt; task to load them into your projects.</P>
<H3>XML Namespace aware</H3>
<P>Ant finally adopts XML namespaces. This is to address build file
scalability; antlibs can be imported into their own namespaces, and
so you can avoid namespace clashes with other libraries. If you do
not know what namespaces are, do not worry -they are not compulsory.</P>

<h3>All tasks can go in at the toplevel</h3>
<p>
 
Prior to Ant1.6, only three tasks were allowed outside 
targets : &lt;taskdef&gt;,&lt;typedef&gt; and &lt;property&gt;.
Ant 1.6 puts an end to this distinction; anything can go in at the top
level. This is partly because there were many more tasks that merited the 
option based on the original rationale of "global initialization tasks":
&lt;import&gt; and &lt;antlib&gt; were the new additions, but existing
tasks like &lt;condition&gt;, &lt;available&gt;, &lt;xmlproperties&gt; 
and &lt;loadproperties&gt; had equal rights. 
</p>
<p>
Rather that expand the set slightly, now all tasks are allowed outside
targets. This gives external tasks the same rights as built in code,
eliminates sporadic bug reports, and annoying error messages. It gives
users the ability to write build files without any targets at all; the
top-level declarations are processed in sequence. 
</p>

On a style note, we strongly advocate using this feature carefully. It
is best if zero-side-effect, initialization-only tasks get put into the
top level. Remember also that all top level statements are processed in
order, before any targets are executed. Even tasks at the end of the
file will get executed before targets declared above them. 

<H2>New Tasks</H2>
<P>As usual, the task base is growing and expanding. These days the
ant core is resisting adopting many of the highly worthy donations of
tasks from people, because they make maintenance and firefighting
worse. Our current stance is that except in special circumstances,
Ant tasks to support third party open source projects, should live
with the projects themselves. This keeps them in sync with the
libraries they integrate with, avoids GPL/Apache licensing issues,
and reduces the Ant team's support workload, letting them focus on
the core. The antlib mechanism is intended to make it easier for
people to load tasks from libraries for this very reason.</P>
<P>That said, we are pleased to introduce many new tasks. Of
particular interest may be the SSH tasks, which let one deploy code
to remote servers securely. Now you really can do live updates with
Ant -if the operations team will let you. The other one that is quite
interesting is &lt;subant&gt;. This is an extension of the &lt;ant&gt;
task, to take an entire fileset of directories and run their build
files. This is incredibly useful in very large projects. This does
not mean that we are advocating the many-build-file development
pattern, but in a sufficiently complex project it happens anyway.
&lt;subant&gt; keeps things manageable.</P>
<H2>What else</H2>
<P>So, what is new in Ant1.6? Lots of stuff. You will have to look at
the <A HREF="WHATSNEW">whatsnew</A> file to see, but here are some
key points. 
</P>
<OL>
	<LI><P STYLE="margin-bottom: 0in">Bug fixes. We know, some things
	were broken in 1.5. In ant1.6 we have moved the bugs, fixing the
	ones we could, and no doubt adding different ones. Hopefully the
	total bug count has decreased. 
	</P>
	<LI><P STYLE="margin-bottom: 0in">New platforms: Open VMS and HP's
	NonStop Kernel (Tandem) OS. OpenVMS is very different from the rest;
	Read the &lt;exec&gt; task documentation carefully. 
	</P>
	<LI><P STYLE="margin-bottom: 0in">Spawning. &lt;java&gt; and &lt;exec&gt;
	started applications can outlive Ant if you set spawn=true. Note
	that the moment you do so, Ant cannot bind to their input or output,
	for obvious reasons. 
	</P>
	<LI><P>Synchronisation with Java versions (heh, thought by moving
	javah's entry point that you could hide from us? Think again).</P>
	<LI><P>Synchronization with third party libraries. Of special note:
	we have moved to the Apache commons-net.jar, the successor to
	NetComponents for telnet and FTP as well as Apache BSF, the
	successor to IBM BSF, for script.</P>
</OL>
<P>There are many more enhancements, so we hope you will find your
build projects easier. We have, as usual, jumped through hoops to
keep existing builds working. If your build file stops working, and
it isn't something listed on the 'changes that may break your build'
part of the WHATSNEW file, or something we know about on bugzilla,
please don't hesitate to file a new bug report, preferably one with a
replicable test and a patch to fix the problem. Please, please,
please, do a search on bugzilla first. You do not want to be the
seventy-third person to complain that Ant1.6 doesn't do something
that it should. 
</P>
<P>Thanks, 
</P>
<P>The Ant development team. 
</P>
<H3>Acknowledgements</H3>
<UL>
	<LI><P>Many thanks for Antoine to being the build manager for this
	release! 
	</P>
	<LI><P>Thank you to everyone who supplies the components we use in
	Ant, particularly JUnit, commons-logging, log4J, bcel, ORO, Xerces, and Xalan. 
	</P>
	<LI><P>Everyone who has supplied bug reports, especially those with
	patches and tests.</P>
	<LI><P>IDE projects who incorporate Ant into their products. Not
	only does this help Ant's success, you find lots of interesting
	integration defects. Special mention to the Eclipse team for fixing
	our memory leaks :)</P>
</UL>
<H3>Call to Action</H3>

<P>

It is an interesting time for Java. .NET is a serious challenger, and
will get better. A core strength of Java over .NET is its community. It
is the community that gave the world leading edge development tools and
other core components: Ant, JUnit, XDoclet, hsqldb, Hibernate, Struts,
etc. These things weren't created by JCP committees, or built according
to the strategic vision of a Fortune 100 company. They were written by
Java developers, for Java developers, usually to meet their own tactical
goals.

</P>

<P>If Java is to survive -and we think it ought to- everyone who can
needs to become active members of that community. It could be helping
with Ant, but it could just as easily be helping with any other open
source Java project, be hosted by Apache, FSF, Sourceforge or someone
else, be it server-side, client-side or mobile-side. It could be an
existing project, or it could be your own idea as to how things could
be better. The key is: things will only be better if you put in the
time to make it so. 
</P>
<H3>Call to Inaction</H3>
<P>A special message to whoever it is in charge of commands in
tools.jar: stop moving your entry points! In Ant1.5 we had to deal
with the 'classic' javac entry point going away in Java1.4.0,
seemingly coming back later. In Java 1.4.2, the javah entry point
moved. The traditional command line invocation mechanism has been
replaced by hosted invocation -Ant, Maven, IDEs, etc, and moving
entry points around breaks these host applications. Even if we get a
bug fix out in Ant a few weeks after the Java release, it takes
months for this to trickle down to end users, especially via IDEs and
other distributions. For example, Sun's own Java Web Services
Developer Pack ships with Ant1.5.1, and so cannot run &lt;javah&gt;
on a 1.4.2 installation. 
</P>
</BODY>
</HTML>