stevel 2003/09/27 00:04:19 Modified: . Tag: ANT_16_BRANCH welcome.html Log: Updated welcome note. written in OpenOffice, hence the " strings, and other quirks. Revision Changes Path No revision No revision 1.2.2.1 +274 -124 ant/welcome.html Index: welcome.html =================================================================== RCS file: /home/cvs/ant/welcome.html,v retrieving revision 1.2 retrieving revision 1.2.2.1 diff -u -r1.2 -r1.2.2.1 --- welcome.html 9 Jul 2002 21:05:49 -0000 1.2 +++ welcome.html 27 Sep 2003 07:04:19 -0000 1.2.2.1 @@ -1,124 +1,274 @@ -<html> -<head> -<title>Welcome to Ant1.5</title> -</head> -<body bgcolor="#ffffff"> -<h1>Welcome to Ant1.5</h1> -Hello, and welcome to Ant1.5 -<p> -For new users to Ant, welcome to a new way to build your software. -<p> -For veteran Ant users, its been, what nine months since Ant 1.4.1 -shipped, and we've been as busy enhancing it as you've been using it. -<p> - -We know you've been using Ant, not just from the all the bug reports we -see, but from the awards we've been getting from JavaWorld and SD Magazine -and from the fact that it is now clearly a mainstream product. Every quality IDE, -from the Open Source projects: Emacs, NetBeans, Eclipse, JEdit, to the -commercial offerings such as IntelliJ IDEA and JBuilder now have high -quality Ant integration either built in or available as a -download. And they do that not just because it improves their products, -giving users the best of both worlds -great editors and a great build -process, but because Java developers are starting to expect Ant (and -JUnit) everywhere. -<p> -Even in mid-2001, if you said you were using Ant in your project, people -would stare at you. Now, as long as you are talking with Java developers -and not management or your family and friends, people will nod, shrug -and maybe ask you questions about build file and Ant configurations. The good -news: Ant 1.5 includes more helpful error messages and a new -<tt>-diagnostics</tt> command to look at your Ant installation and help work out why -things arent working. -<p> -Now, when you tell people you work on Ant in your spare time, -people used to give you very funny stares; now they ask you about how to -set up automated build processes, or deploy to some random app server. -The good news: Ant 1.5 makes it easier to answer those questions. - -The other sign of mainstream is that there are also books on the -subject, first Java Tools for Extreme Programming, then Ant: The -Definitive Guide, and the first Ant1.5 book, Java Development with Ant, -due to ship at the end of the month. (Steve says: I prefer the one with -my name on the cover as co-author, but I'm biased). -As usual, the manual has improved too: -regardless of whether you need a book to work with Ant or not, you need -that on-line documentation. And as usual, any extra contributions to the -docs are welcome indeed. -<p> -Ant has also influenced how projects are built. Now when you download -any open source project, or work with a closed source team, you expect -to see a file called build.xml there. Equally important, you expect that -build file to compile and run a set of tests using JUnit or a derivative -thereof; if they are missing, you worry. -<p> -Together, Ant and JUnit have transformed the mainstream process for -building and deploying Java projects. And that's pretty profound, when -you think about it. What is equally impressive is that this was all done -as a co-operative effort. Nobody works on Ant full-time; everybody uses -it to solve their problems, to address their build crises and generally -get something done in a hurry. It just so happens that the architectural -model of Java classes bound via introspection to the XML build file -makes it easy for people to add new tasks, extend existing ones and -generally ease their way into developing and extending Ant. It is the -users that have helped Ant become the success it is today, and will keep -it that way tomorrow. -<p> -<h2>What has changed</h2> -<p> -So, what is new in Ant1.5? Lots of stuff. You will have to look at the -<a href="WHATSNEW">whatsnew</a> file to see, but basically the changes -fall into a number of categories -<ol> -<li>Bug fixes. We know, some things were broken in 1.4. In ant1.5 we -have moved the bugs, fixing the ones we could, and no doubt adding -different ones. Hopefully the total bug count has decreased. -<li>Scalability. Changes in <ant> and a few other tasks should -make it easier to write large, scalable build files. -<li>Deployment. Take a look at the new <serverdeploy> task, add support -for your server if it isnt there. Tomcat 4.1 has its own deployment -tasks incidentally -fetch them from the tomcat pages. -<li>Ease of use. We have added new attributes to make the archive tasks -consistent with each other, new error messages for common problems (you -get a screenful of help when a task wont instantiate, for example), and -generally try and be helpful. As usual, we will accept contributions to -the documentation or the code for even more helpfulness. Hey, in ant1.5 -you dont need to double escape the $ sign to preserve it in a string! -<li>Java 1.4 support. We build and test fine on Java 1.4, and have the -extensions to javac needed to build code with assertions in. We should -point out that we have more work to do in this area: if someone wants to -write an <assertionset> datatype to give users control of which assertions -to enable, and patch this in to things like the <junit> and -<java> tasks, things would get very interesting. -<li>Continuous builds. Automated build tools are becoming more widely -used; fork options on <javac> and <javadoc> are there to -stop memory use growth on a continuous process. -<li>New platforms: MacOS X for owners of those cute little laptops, -Novell Netware servers, and even z/OS and OS/390 for mainframe -developers who write their build files on their virtual card punches. -<li>Conditions. Take a look at the <condition> tag to see what you can -look for, then at <waitfor> to use the same tests in deployment. -Finally, notice the <tt>if</tt> and <tt>unless</tt> attributes on -<fail> for easy halting of the build on a condition, without -having to resort to conditional targets. -</ol> - -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, even those build files that went out their way -to not work on Java 1.4 (hint: dont ask for the classic compiler, it has -gone away). If your build file stops working, and it isnt something listed -on the 'changes that may break your build' part of the WHATSNEW file, or -something we know about on bugzilla, please dont hesitate to file a new -bug report, preferably one with a replicable test and a patch to fix the -problem. -<p> -Thanks, -<p> -The Ant development team. -<p> -PS: many thanks for Magesh to being the build manager for this release! -He has been busy since Feb/March organizing it. Magesh -you are so good -at this you should do it next time too :) -</body></html> - +<!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 Ant1.5</TITLE> +</HEAD> +<BODY LANG="en-US" BGCOLOR="#ffffff" DIR="LTR"> +<H1>Welcome to Ant1.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 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 +if="${property}" 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 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 Ant1.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 to 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> +<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.</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 +</P> +<P>Thanks, +</P> +<P>The Ant development team. +</P> +<P>PS: many thanks for Antoine to being the build manager for this +release! +</P> +</BODY> +</HTML>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
