123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352 |
- <!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 <taskdef> existing tasks -like <junit>-
- 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>> arbitrary Java
- classes into ant tasks or types. There has always been some of this
- stuff inside Ant, but now you can <taskdef> 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 <taskdef> and <typedef>. 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 <taskdef> and <typedef>, 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
- <javac> 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 <taskdef> 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 : <taskdef>,<typedef> and <property>.
- 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":
- <import> and <antlib> were the new additions, but existing
- tasks like <condition>, <available>, <xmlproperties>
- and <loadproperties> 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 <subant>. This is an extension of the <ant>
- 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.
- <subant> 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 <exec> task documentation carefully.
- </P>
- <LI><P STYLE="margin-bottom: 0in">Spawning. <java> and <exec>
- 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 <javah>
- on a 1.4.2 installation.
- </P>
- </BODY>
- </HTML>
|