diff options
| author | wisberg <wisberg> | 2005-05-11 08:40:10 +0000 |
|---|---|---|
| committer | wisberg <wisberg> | 2005-05-11 08:40:10 +0000 |
| commit | e458b498824ab0ecf898503bdc8e682dfc272ce8 (patch) | |
| tree | ea0f5056bae2c1c1177ce9874f618ba1efd29548 /lib/ant/welcome.html | |
| parent | a30b4b76da6491d53c364a8c805bb2d3d805c16c (diff) | |
| download | aspectj-e458b498824ab0ecf898503bdc8e682dfc272ce8.tar.gz aspectj-e458b498824ab0ecf898503bdc8e682dfc272ce8.zip | |
Ant 1.6.3 (again? hmm.)
Diffstat (limited to 'lib/ant/welcome.html')
| -rw-r--r-- | lib/ant/welcome.html | 352 |
1 files changed, 352 insertions, 0 deletions
diff --git a/lib/ant/welcome.html b/lib/ant/welcome.html new file mode 100644 index 000000000..1e2a27b94 --- /dev/null +++ b/lib/ant/welcome.html @@ -0,0 +1,352 @@ +<!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>
\ No newline at end of file |