ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r439488 [1/13] - in /ant/site: ./ generated/ generated/ant2/ generated/antlibs/ generated/antlibs/antunit/ generated/antlibs/dotnet/ generated/antlibs/svn/ generated/images/ generated/projects/ generated/webtest/
Date Fri, 01 Sep 2006 21:41:43 GMT
Author: bodewig
Date: Fri Sep  1 14:41:40 2006
New Revision: 439488

complete site

    ant/site/generated/LICENSE   (with props)
    ant/site/generated/ant2/FunctionalRequirements.html   (with props)
    ant/site/generated/ant2/VFS.txt   (with props)
    ant/site/generated/ant2/actionlist.html   (with props)
    ant/site/generated/ant2/features.html   (with props)
    ant/site/generated/ant2/original-specification.html   (with props)
    ant/site/generated/ant2/requested-features.html   (with props)
    ant/site/generated/ant2/requested-features.txt   (with props)
    ant/site/generated/ant_in_anger.html   (with props)
    ant/site/generated/ant_task_guidelines.html   (with props)
    ant/site/generated/antlibs/antunit/index.html   (with props)
    ant/site/generated/antlibs/bindownload.cgi   (with props)
    ant/site/generated/antlibs/bindownload.html   (with props)
    ant/site/generated/antlibs/charter.html   (with props)
    ant/site/generated/antlibs/dotnet/index.html   (with props)
    ant/site/generated/antlibs/index.html   (with props)
    ant/site/generated/antlibs/proper.html   (with props)
    ant/site/generated/antlibs/sandbox.html   (with props)
    ant/site/generated/antlibs/srcdownload.cgi   (with props)
    ant/site/generated/antlibs/srcdownload.html   (with props)
    ant/site/generated/antlibs/svn/index.html   (with props)
    ant/site/generated/antnews.html   (with props)
    ant/site/generated/bindownload.cgi   (with props)
    ant/site/generated/bindownload.html   (with props)
    ant/site/generated/breadcrumbs.js   (with props)
    ant/site/generated/bugs.html   (with props)
    ant/site/generated/bylaws.html   (with props)
    ant/site/generated/contributors.html   (with props)
    ant/site/generated/external.html   (with props)
    ant/site/generated/faq.html   (with props)
    ant/site/generated/favicon.ico   (with props)
    ant/site/generated/images/JDJEditorsChoiceAward.jpg   (with props)
    ant/site/generated/images/ant_logo.ico   (with props)
    ant/site/generated/images/ant_logo_large.gif   (with props)
    ant/site/generated/images/ant_logo_medium.gif   (with props)
    ant/site/generated/images/ant_logo_small.gif   (with props)
    ant/site/generated/images/beta.png   (with props)
    ant/site/generated/images/current.gif   (with props)
    ant/site/generated/images/group-logo.gif   (with props)
    ant/site/generated/images/jp_rcwinner_2003.gif   (with props)
    ant/site/generated/images/jw_ec_logo_winner2002.gif   (with props)
    ant/site/generated/images/jw_ec_logo_winner2003.gif   (with props)
    ant/site/generated/images/label.gif   (with props)
    ant/site/generated/images/menu-left.gif   (with props)
    ant/site/generated/images/menu-right.gif   (with props)
    ant/site/generated/images/page.gif   (with props)
    ant/site/generated/images/printer.gif   (with props)
    ant/site/generated/images/project-logo.gif   (with props)
    ant/site/generated/images/sdm_productivity_award.gif   (with props)
    ant/site/generated/images/search-left.gif   (with props)
    ant/site/generated/images/search-right.gif   (with props)
    ant/site/generated/images/spacer.gif   (with props)
    ant/site/generated/images/tab-left.gif   (with props)
    ant/site/generated/images/tab-right.gif   (with props)
    ant/site/generated/images/tabSel-left.gif   (with props)
    ant/site/generated/images/tabSel-right.gif   (with props)
    ant/site/generated/index.html   (with props)
    ant/site/generated/legal.html   (with props)
    ant/site/generated/license.html   (with props)
    ant/site/generated/mail.html   (with props)
    ant/site/generated/mission.html   (with props)
    ant/site/generated/page.css   (with props)
    ant/site/generated/problems.html   (with props)
    ant/site/generated/projects.html   (with props)
    ant/site/generated/projects/index.html   (with props)
    ant/site/generated/resources.html   (with props)
    ant/site/generated/srcdownload.cgi   (with props)
    ant/site/generated/srcdownload.html   (with props)
    ant/site/generated/svn.html   (with props)
    ant/site/generated/webtest/testkeystore   (with props)
    ant/site/   (props changed)

Propchange: ant/site/
--- svn:externals (original)
+++ svn:externals Fri Sep  1 14:41:40 2006
@@ -1 +1,2 @@

Modified: ant/site/build.xml
--- ant/site/build.xml (original)
+++ ant/site/build.xml Fri Sep  1 14:41:40 2006
@@ -23,6 +23,7 @@
     <property name="" value="ant"/>
     <property name=""     location="xdocs"/>
     <property name=""    location="generated"/>
+    <property name=""  location="core-docs"/>
     <property name="project.file" value="stylesheets/project.xml" />
     <property name="templ.path"   location="${}/stylesheets" />
     <property name="velocity.props"   location="${}/" />
@@ -61,6 +62,19 @@
         <fixcrlf srcDir="${}" eol="dos" includes="*.html"/>
-    <target name="docs" depends="anakia,fixcrlf" description="Create XDocs."/>
+  <target name="sync-rest">
+    <sync todir="${}" includeemptydirs="true">
+      <fileset dir="${}">
+        <exclude name="manual/"/>
+      </fileset>
+      <preserveintarget>
+        <include name="manual/"/>
+        <include name="manual-beta/"/>
+        <include name="**/.svn/"/>
+      </preserveintarget>
+    </sync>
+  </target>
+    <target name="docs" depends="anakia,sync-rest,fixcrlf" description="Create XDocs."/>

Added: ant/site/generated/LICENSE
--- ant/site/generated/LICENSE (added)
+++ ant/site/generated/LICENSE Fri Sep  1 14:41:40 2006
@@ -0,0 +1,203 @@
+ *                                 Apache License
+ *                           Version 2.0, January 2004
+ *              
+ *
+ *
+ *   1. Definitions.
+ *
+ *      "License" shall mean the terms and conditions for use, reproduction,
+ *      and distribution as defined by Sections 1 through 9 of this document.
+ *
+ *      "Licensor" shall mean the copyright owner or entity authorized by
+ *      the copyright owner that is granting the License.
+ *
+ *      "Legal Entity" shall mean the union of the acting entity and all
+ *      other entities that control, are controlled by, or are under common
+ *      control with that entity. For the purposes of this definition,
+ *      "control" means (i) the power, direct or indirect, to cause the
+ *      direction or management of such entity, whether by contract or
+ *      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+ *      outstanding shares, or (iii) beneficial ownership of such entity.
+ *
+ *      "You" (or "Your") shall mean an individual or Legal Entity
+ *      exercising permissions granted by this License.
+ *
+ *      "Source" form shall mean the preferred form for making modifications,
+ *      including but not limited to software source code, documentation
+ *      source, and configuration files.
+ *
+ *      "Object" form shall mean any form resulting from mechanical
+ *      transformation or translation of a Source form, including but
+ *      not limited to compiled object code, generated documentation,
+ *      and conversions to other media types.
+ *
+ *      "Work" shall mean the work of authorship, whether in Source or
+ *      Object form, made available under the License, as indicated by a
+ *      copyright notice that is included in or attached to the work
+ *      (an example is provided in the Appendix below).
+ *
+ *      "Derivative Works" shall mean any work, whether in Source or Object
+ *      form, that is based on (or derived from) the Work and for which the
+ *      editorial revisions, annotations, elaborations, or other modifications
+ *      represent, as a whole, an original work of authorship. For the purposes
+ *      of this License, Derivative Works shall not include works that remain
+ *      separable from, or merely link (or bind by name) to the interfaces of,
+ *      the Work and Derivative Works thereof.
+ *
+ *      "Contribution" shall mean any work of authorship, including
+ *      the original version of the Work and any modifications or additions
+ *      to that Work or Derivative Works thereof, that is intentionally
+ *      submitted to Licensor for inclusion in the Work by the copyright owner
+ *      or by an individual or Legal Entity authorized to submit on behalf of
+ *      the copyright owner. For the purposes of this definition, "submitted"
+ *      means any form of electronic, verbal, or written communication sent
+ *      to the Licensor or its representatives, including but not limited to
+ *      communication on electronic mailing lists, source code control systems,
+ *      and issue tracking systems that are managed by, or on behalf of, the
+ *      Licensor for the purpose of discussing and improving the Work, but
+ *      excluding communication that is conspicuously marked or otherwise
+ *      designated in writing by the copyright owner as "Not a Contribution."
+ *
+ *      "Contributor" shall mean Licensor and any individual or Legal Entity
+ *      on behalf of whom a Contribution has been received by Licensor and
+ *      subsequently incorporated within the Work.
+ *
+ *   2. Grant of Copyright License. Subject to the terms and conditions of
+ *      this License, each Contributor hereby grants to You a perpetual,
+ *      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ *      copyright license to reproduce, prepare Derivative Works of,
+ *      publicly display, publicly perform, sublicense, and distribute the
+ *      Work and such Derivative Works in Source or Object form.
+ *
+ *   3. Grant of Patent License. Subject to the terms and conditions of
+ *      this License, each Contributor hereby grants to You a perpetual,
+ *      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+ *      (except as stated in this section) patent license to make, have made,
+ *      use, offer to sell, sell, import, and otherwise transfer the Work,
+ *      where such license applies only to those patent claims licensable
+ *      by such Contributor that are necessarily infringed by their
+ *      Contribution(s) alone or by combination of their Contribution(s)
+ *      with the Work to which such Contribution(s) was submitted. If You
+ *      institute patent litigation against any entity (including a
+ *      cross-claim or counterclaim in a lawsuit) alleging that the Work
+ *      or a Contribution incorporated within the Work constitutes direct
+ *      or contributory patent infringement, then any patent licenses
+ *      granted to You under this License for that Work shall terminate
+ *      as of the date such litigation is filed.
+ *
+ *   4. Redistribution. You may reproduce and distribute copies of the
+ *      Work or Derivative Works thereof in any medium, with or without
+ *      modifications, and in Source or Object form, provided that You
+ *      meet the following conditions:
+ *
+ *      (a) You must give any other recipients of the Work or
+ *          Derivative Works a copy of this License; and
+ *
+ *      (b) You must cause any modified files to carry prominent notices
+ *          stating that You changed the files; and
+ *
+ *      (c) You must retain, in the Source form of any Derivative Works
+ *          that You distribute, all copyright, patent, trademark, and
+ *          attribution notices from the Source form of the Work,
+ *          excluding those notices that do not pertain to any part of
+ *          the Derivative Works; and
+ *
+ *      (d) If the Work includes a "NOTICE" text file as part of its
+ *          distribution, then any Derivative Works that You distribute must
+ *          include a readable copy of the attribution notices contained
+ *          within such NOTICE file, excluding those notices that do not
+ *          pertain to any part of the Derivative Works, in at least one
+ *          of the following places: within a NOTICE text file distributed
+ *          as part of the Derivative Works; within the Source form or
+ *          documentation, if provided along with the Derivative Works; or,
+ *          within a display generated by the Derivative Works, if and
+ *          wherever such third-party notices normally appear. The contents
+ *          of the NOTICE file are for informational purposes only and
+ *          do not modify the License. You may add Your own attribution
+ *          notices within Derivative Works that You distribute, alongside
+ *          or as an addendum to the NOTICE text from the Work, provided
+ *          that such additional attribution notices cannot be construed
+ *          as modifying the License.
+ *
+ *      You may add Your own copyright statement to Your modifications and
+ *      may provide additional or different license terms and conditions
+ *      for use, reproduction, or distribution of Your modifications, or
+ *      for any such Derivative Works as a whole, provided Your use,
+ *      reproduction, and distribution of the Work otherwise complies with
+ *      the conditions stated in this License.
+ *
+ *   5. Submission of Contributions. Unless You explicitly state otherwise,
+ *      any Contribution intentionally submitted for inclusion in the Work
+ *      by You to the Licensor shall be under the terms and conditions of
+ *      this License, without any additional terms or conditions.
+ *      Notwithstanding the above, nothing herein shall supersede or modify
+ *      the terms of any separate license agreement you may have executed
+ *      with Licensor regarding such Contributions.
+ *
+ *   6. Trademarks. This License does not grant permission to use the trade
+ *      names, trademarks, service marks, or product names of the Licensor,
+ *      except as required for reasonable and customary use in describing the
+ *      origin of the Work and reproducing the content of the NOTICE file.
+ *
+ *   7. Disclaimer of Warranty. Unless required by applicable law or
+ *      agreed to in writing, Licensor provides the Work (and each
+ *      Contributor provides its Contributions) on an "AS IS" BASIS,
+ *      implied, including, without limitation, any warranties or conditions
+ *      PARTICULAR PURPOSE. You are solely responsible for determining the
+ *      appropriateness of using or redistributing the Work and assume any
+ *      risks associated with Your exercise of permissions under this License.
+ *
+ *   8. Limitation of Liability. In no event and under no legal theory,
+ *      whether in tort (including negligence), contract, or otherwise,
+ *      unless required by applicable law (such as deliberate and grossly
+ *      negligent acts) or agreed to in writing, shall any Contributor be
+ *      liable to You for damages, including any direct, indirect, special,
+ *      incidental, or consequential damages of any character arising as a
+ *      result of this License or out of the use or inability to use the
+ *      Work (including but not limited to damages for loss of goodwill,
+ *      work stoppage, computer failure or malfunction, or any and all
+ *      other commercial damages or losses), even if such Contributor
+ *      has been advised of the possibility of such damages.
+ *
+ *   9. Accepting Warranty or Additional Liability. While redistributing
+ *      the Work or Derivative Works thereof, You may choose to offer,
+ *      and charge a fee for, acceptance of support, warranty, indemnity,
+ *      or other liability obligations and/or rights consistent with this
+ *      License. However, in accepting such obligations, You may act only
+ *      on Your own behalf and on Your sole responsibility, not on behalf
+ *      of any other Contributor, and only if You agree to indemnify,
+ *      defend, and hold each Contributor harmless for any liability
+ *      incurred by, or claims asserted against, such Contributor by reason
+ *      of your accepting any such warranty or additional liability.
+ *
+ *
+ *   APPENDIX: How to apply the Apache License to your work.
+ *
+ *      To apply the Apache License to your work, attach the following
+ *      boilerplate notice, with the fields enclosed by brackets "[]"
+ *      replaced with your own identifying information. (Don't include
+ *      the brackets!)  The text should be enclosed in the appropriate
+ *      comment syntax for the file format. We also recommend that a
+ *      file or class name and description of purpose be included on the
+ *      same "printed page" as the copyright notice for easier
+ *      identification within third-party archives.
+ *
+ *   Copyright [yyyy] [name of copyright owner]
+ *
+ *   Licensed under the Apache License, Version 2.0 (the "License");
+ *   you may not use this file except in compliance with the License.
+ *   You may obtain a copy of the License at
+ *
+ *
+ *
+ *   Unless required by applicable law or agreed to in writing, software
+ *   distributed under the License is distributed on an "AS IS" BASIS,
+ *   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ *   See the License for the specific language governing permissions and
+ *   limitations under the License.
+ */

Propchange: ant/site/generated/LICENSE
    svn:eol-style = native

Added: ant/site/generated/ant2/FunctionalRequirements.html
--- ant/site/generated/ant2/FunctionalRequirements.html (added)
+++ ant/site/generated/ant2/FunctionalRequirements.html Fri Sep  1 14:41:40 2006
@@ -0,0 +1,54 @@
+  <meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
+  <title>Ant Functional Requirements Document</title>
+<h2>Ant Functional Requirements</h2>
+<p><b>User: </b>runs Ant with a complete build specification and/or
+writes Ant build specifications.</p>
+<p><b>Task Developer: </b>writes/modifies Ant tasks.</p>
+<p><b>Extensions Developer: </b>develops extensions like a GUI, IDE plugin,
+ (scripting extension?)</p>
+<p><b>Core Developer: </b>works on the Ant core</p>
+<h3>Requirements from the Ant User perspective</h3>
+<p>It should be easy to write a build file for small Java programs. It should
+ be possible to write a build file set for large Java systems. Maintenance
+ of such a set should be easy (e.g. no duplication of information).</p>
+<p>Every build process contains dependencies (e.g. item A needs B to be available
+ before its own build can start). It should be possible to specify these
+ dependencies in a declarative way.</p>
+<p>Suppose a working build specification for system A is available. It should
+ be possible for system B to declare dependencies to <i>(modules of?)</i> system
+ A without touching the build specification of A. Ant should be able to handle
+ dependencies between modules which form a DAG.</p>
+<p>It should be possible to modify details of the actual build (e.g. classpath,
+ used compiler) without the need to change the build specification. This
+ feature is needed when starting Ant (e.g. configuration with command line
+ parameters) and for a subproject build driven by the build of a dependent
+ project.</p>
+<p>Often similar items have to be built. Therefore it should be possible
+ to provide general <i>(template?)</i> build specifications, and to declare for
+ a concrete item that it should be built according to such a general specification.</p>
+<p>One result of the build process should be a log which shows what has been done.</p>
+<h3>Requirements from the task developer perspective</h3>
+<p>A task should not need to know the structure of a build specification.
+ It would have to provide an interface (not necessarily in the Java language
+ sense) for the Ant core to input the necessary configuration attributes
+ and to execute the task). There should be a standard functionality to allow
+ a task doing log output.</p>
+<p>An interface (again not necessarily in the Java language sense) should
+ be provided which allows a task to get <i>(and set?)</i> information about it's
+ context in the build process.</p>
+<h3>Requirements from the extensions developer perspective</h3>
+<p>The Ant core should be independent from a specific representation of the
+ build specification. It should be possible to create a specification programmatically
+ (thereby allowing the introduction of new representations). The core should
+ do no in- or output itself. Build errors should always lead to throwing
+ an Exception.</p>
+<p>Access to the current state of a build should be available, and its modification
+ possible.</p>

Propchange: ant/site/generated/ant2/FunctionalRequirements.html
    svn:eol-style = native

Added: ant/site/generated/ant2/VFS.txt
--- ant/site/generated/ant2/VFS.txt (added)
+++ ant/site/generated/ant2/VFS.txt Fri Sep  1 14:41:40 2006
@@ -0,0 +1,237 @@
+From: "Adam Murdoch" <>
+Subject: RE: Virtual FileSystem Layer
+Date: Sat, 22 Dec 2001 12:06:37 +1000
+I've also been doing a bit of work on the VFS.  No code yet - instead, I've
+done a survey of the Ant 1 code, to help get a better idea of what we need
+the VFS to actually do.
+I've put together a rough list of the sort of features the current tasks
+require from the file system.  This list is entirely from the task writer's
+POV.  I've ignored the build file writer completely - though, the action
+list is a good summary of the build file writer's concerns.  I've tried to
+steer clear of assumptions about what is actually going to provide each
+feature to the tasks, or what the API will look like to the tasks.
+The goal for doing up this list, was to help identify the features we want
+to support, and the API that the tasks will use to get at them.  This should
+be largely independent of how we decide to represent the file system in the
+build files.  In addition, it doesn't matter too much whether the list below
+is complete (I'm sure it isn't), or that the VFS provide every single one of
+the features.  Whatever it doesn't provide, can stay up in the tasks, and be
+refactored down later.
+The assumption here is that we do actually want to put together a file
+system API.  I think it's a good idea to at least put together some
+interfaces, even if the implementation is stolen from somewhere else.
+Without a doubt, the file system is the most widely used "service" in the
+current crop of tasks.  The API that we choose has to have a good semantic
+match with what the tasks need to do, so that writing the tasks is easy.
+The API also has to be general enough to deal with stuff we haven't thought
+of yet.  On that note, I personally think that JNDI might be a touch too
+general for what we need.
+So, the features.  Note that many of these will be optional - not every
+feature will be available for every node in the file system.  I've used the
+term "node" to mean both directories and files.  I'm not suggesting we
+actually call them "nodes" in the API.  I've used the term "root node" to
+mean the root of a file system.
+* Naming
+- Locate a node by absolute name.
+- Get the absolute name for a node.
+- Resolve a name to a node, relative to some base node - like
+- Get the relative name of a node, relative to some base node.
+- Determine the base name (with and without the extension), and extension of
+the node.
+- Deal with file systems that are case sensitive, and case insentitive.
+* Properties
+- Determine what properties are available on the node.
+- Determine if the node exists.
+- Determine the type of node (file vs. directory, could be "has-content" vs
+- Determine if the node is readable.
+- Determine if the node is writeable.
+- Get/set the permissions on the node.  This covers things like chmod &
+chown, making read-only, making executable, etc.
+* Content
+- Determine if the node can/does have content.
+- Get the size of the node.
+- Get/set the last-modified time of the node.
+- Get/set the mime-type of the node.
+- Get/set the encoding of the node.
+- Get a checksum of the node.
+- Get content as InputStream.
+- Get content as Reader.
+- Set content as an OutputStream.
+- Set content as a Writer.
+- Implicit creation of node and its ancestors when content is written.
+- Compare nodes for equality (last modified timestamp, checksum, bytewise
+* Hierarchy
+- Get the parent node of a node.
+- Get the child nodes of a node.
+- Iterate over (or visit) the descendants of a node.
+  - With or without a selector.
+  - In various orders - depthwise, etc.
+  - Be able to modify the nodes during traversal.
+* Modification
+- Create a new node of a particular type.  Create all missing ancestors.
+- Move, copy, delete a node.
+  - All descendants.
+  - Optional selector. E.g. ignore empty dirs, ignore default excludes, etc.
+  - Optional filter.
+* Conversion
+- Convert the node to a
+- Make the node content available as a local file (to hand off to external
+- Get the OS specific *filename* for a node.
+- Resolve an OS specific *filename* to a node.
+* File System Types
+- Local file.
+- HTTP.
+- FTP.
+- Classloader, uses Classloader.getResource().
+- Temporary files.
+- etc ...
+- Compound file system.  Made up of a bunch of mount points.  The VFS
+- Layered file systems (that sit on top of another file system or node):
+  - zip, bzip, jar, tar
+  - filtering - token replacement, etc
+- Factories for creating and configuring file system root nodes.
+- Ability to easily add new file system implementations.
+* Task Container
+- A mechanism for a task to get hold of the project's root node.
+- A mechanism that allows a task to create its own private root nodes,
+without letting it mess with the project's file system, or the file systems
+of other tasks.
+- A mechanism for cleaning up all the node InputStream, OutputStream, Reader
+and Writers opened by a task during its execute() method.  Cleaning up files
+is one thing the current tasks don't do very well at all.  Something like
+this would take care of anything the task did not explictly close.  Would
+include root nodes it created.
+* Other things
+- Maybe some way to explicitly close a node and release all resources used
+by it.
+- Maybe detection of concurrent updates, in the case of parallel tasks.
+- Netbeans has an event model in its VFS.  Something like this might be
+useful in dependency management.
+- nodesets.  The replacement for, or generalisation of, FileSet, Path,
+FileList, etc
+  - A nodeset that contains the descendents of a node that match a selector
+(like the current FileSet implementation).
+  - A nodeset that contains arbitrary nodes.
+  - An aggregating nodeset.
+  - Custom nodeset implementations.
+- Reimplement the Ant 1 Fileset, Path and Filelist as adaptors sitting on
+top of the VFS.
+- A classloader that can load classes from a node.
+- etc ..
+What's missing?  What shouldn't be on the list?
+> -----Original Message-----
+> From: Magesh Umasankar
+> Sent: Saturday, 22 December 2001 10:44 AM
+> To:
+> Subject: Virtual FileSystem Layer
+> I have been spending some time now on the VFS
+> layer...  Nothing major to report yet, but I just wanted
+> to sound off so that if I am going down the wrong
+> route, I correct it right away.
+> I evaluated at WebNFS, NetBeansFS (NBFS) and
+> JNDI.
+> 1.  WebNFS seems to be going nowhere.  It has
+> been dormant for quite sometime now.  Licensing
+> is rigid.  Technically, it doesn't look so bad as it
+> closely replicates's API.  But then,
+> that really gives us very little.
+> 2.  NBFS looks OK.  It has got a few filesystems
+> already built.  There may be some licensing issues,
+> I don't know, but that shouldn't concern us too
+> much as, according to Peter, it is Mozilla (I haven't
+> really check the license out, sorry).  But, as far as I
+> can see, it seems to lack in sophisticated API features
+> like searching based on attributes, etc., which
+> we will definitely be needing for the Selector APIs.
+> 3.  JNDI, by far, beats the above to, in my
+> evaluation.  It is generic enough.  We don't have
+> any licensing issues.  It has also become part of
+> the core JRE (1.4 onwards).  Technically, it fits to a T
+> what we are looking for - virtual file system that
+> provides search controls, access attributes,
+> url mounting, etc.  Furthermore, there's been
+> some ground work already done for us at Jakarta/Apache
+> (Catalina).  I have written a SPI for a FTPFileSystem
+> - though it is in a real crude stage right now.  I believe
+> this is the way to go because Ant's code would be
+> operating at the (Dir)Context level and we can keep
+> adding SPIs as we need them.  Furthermore,
+> JNDI has been stable for quite sometime now and
+> we can depend on a widely used API.
+> I don't think JNDI is a heavyweight API for our needs.
+> It seems to be the only one, so far, which encompasses
+> at the APIP level, all the new functionalities that we
+> desire to introduce.
+> Let me know if my approach, so far, to go the JNDI
+> route seems reasonable.
+> Cheers,
+> Magesh
+> --
+> To unsubscribe, e-mail:   <>
+> For additional commands, e-mail: <>
+To unsubscribe, e-mail:   <>
+For additional commands, e-mail: <>

Propchange: ant/site/generated/ant2/VFS.txt
    svn:eol-style = native

Added: ant/site/generated/ant2/actionlist.html
--- ant/site/generated/ant2/actionlist.html (added)
+++ ant/site/generated/ant2/actionlist.html Fri Sep  1 14:41:40 2006
@@ -0,0 +1,476 @@
+  <head><title>Ant1.9 Action List</title></head>
+  <body bgcolor="#ffffff">
+  <center>
+    <h1>Ant1.9 Action List</h1>
+    <h2>Precursor to Ant2</h2>
+    <i>Peter Donald [<a href="mailto:peter at">peter at</a>]</i>
+  </center>
+  <div align="center">
+  <table width="80%"><tr><td>
+    <blockquote>
+    <p>
+      This document aims to contain a list of actions that people can take
+      to produce Ant1.9. Ant1.9 is a refactoring of the Ant1.x line and a jump
+      point for Ant2. Some changes will be backported to Ant1.x over time when 
+      they have proven themselves while other changes may only become available
+      via Ant2.0. Ant1.9 is our melting pot where we can experiment and refactor 
+      without a thought to backwards compatability but only to the "right" way 
+      of doing things.
+    </p>
+    </blockquote></td></tr>
+  </table>
+  </div>
+  <h2>Introduction</h2>
+  <blockquote>
+    <p>
+      This document will list a bunch of actions that will guide us in the evolution 
+      of Ant1.x and provide a solid basis on which to launch Ant2.0. Feel free to add to 
+      this list of actions as our vision of Ant2 solidifies. Associated with each action
+      is a list of victims who have "volunteered" to have a go at the action and a status.
+      The status just tells us where they are at while the victim column will tell us exactly
+      who is doing what. It is fine for a group of people to work on a single area.
+    </p>
+    <br />
+    <br />
+    <br />
+    <div align="center">
+    <table cellspacing="2" cellpadding="5" width="80%">
+      <tr>
+        <td bgcolor="#eeeeee" align="center">Action</td>
+        <td bgcolor="#eeeeee" align="center">Victims</td>
+        <td bgcolor="#eeeeee" align="center">Status</td>
+      </tr>
+      <tr>
+        <td><a href="#vfs">Create a Virtual Filesystem layer</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#naming">Formalize a naming scheme for task attributes/elements</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#selector">Design and implement s Selector API for Filesets and other Itemsets</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#coloring">Develope the infrastructure for coloring (or "environmental" dependency analysis)</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#structural">Develope the infrastructure for structural dependency analysis</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#exec">Refactor the Exec infrastructure into JavaBeans</a></td>
+        <td>Peter Donald</td>
+        <td>80%</td>
+      </tr>
+      <tr>
+        <td><a href="#java">Refactor the Java infrastructure into JavaBeans</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#facade">Design and implement a generic solution for creating Task facades</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#packaging">Sketch out a basic way of separating all the tasks into type libraries</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#mapperext">Design and implement an API that allows mapping of file attributes during copy/move/etc tasks</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#filters">Design and implement an API so that Filters could be implemented as FilteredOutputStreams</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#catalog">Design and implement a XML "catalog" so the snippets of XML can be injected based on URI rather than relative location</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#i18n">Look at the feasability of i18n'ing tasks and the runtime</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#doco">Write a document describing the way that tasks should be written in context of Ant2</a></td>
+        <td>Peter Donald<br />(peter at</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#embeddor">Design an API to embed Ant into other applications</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#info">Design a TypeInfo system similar to BeanInfo to describe Tasks</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+      <tr>
+        <td><a href="#antdoc">Design Antdoc to generate manual from .java files</a></td>
+        <td>None</td>
+        <td>Not Started</td>
+      </tr>
+    </table>
+    </div>
+  </blockquote>
+  <h3>Virtual File System</h3>
+  <a name="vfs" />
+  <blockquote>
+    <p>
+      There has long been a recognition that it would be nice if ant supported some 
+      notion of a virtual filesystem layer. This layer would allow you to treat 
+      resources located and retrieved from different mechanisms in a uniform way.
+      For instance it would allow the copy task to copy from a http server, a cvs server,
+      a ftp server or the local filesystem using a uniform mechanism. So instead of
+      having separate tasks to operate on each different resource type we would use
+      just one task that plugged into multiple filesystems.
+    </p>
+    <p>
+      When we are talking about a virtual filesystem or VFS, one of the concerns we must 
+      address is how to "name" the resource. In most cases a URL or URI style access will 
+      be sufficient but in other cases we may need to consider other options. So 
+      "cvs://localhost:/home/cvs/jakarta-avalon/README.txt?version=1.1", 
+      "" and "file://C/WINDOWS/Desktop/MyFile.txt"
+      are all examples of referring to different resources.
+    </p>
+    <p>
+      Another concern that must be addressed is capabilities of both the resources and
+      the filesystem. For instance it is possible to both read and write to resources
+      using the "file" protocol but only possible to write resources using "mailto".
+      The act of copying a file to a "mailto" url would actuall post the files as 
+      resources while copying to a "file" would duplicate the resource somewhere on 
+      the local filesystem. 
+    </p>
+    <p>
+      So we need to determine a list of capabilities. Some examples would be "read", 
+      "write", "list" (can you list dirs), "type" (can you get mime type), 
+      "access permissions" (can you tell if resource has permissions), 
+      "modify permissions" (can you modify permissions) etc. Some of these capabilities
+      can be associated with the particular reosurces, while others may need to be 
+      associated with a whole filesystem/protocol (ie there is no standard mechanism
+      to perform "list" on general "http" URLs). Thus a list of all these capabilities
+      and mapping to various protocols will need to be established.
+    </p>
+    <p>
+      Next we need to determine if we are going to support the notion of "mounting"
+      URLs. For instance if we need to copy files from a FTP server do we allways
+      need to specify the full URL - no matter how convoluted it is (ie
+      "")
+      or can we mount this on a VFS and access it via that shorter url. ie We could 
+      mount "" onto "vfs:/home" 
+      and then just access the resources via "vfs:/home/project2/dir/".
+      This would make dealing with large urls easier and more uniform.
+    </p>
+    <p>
+      So after we have decided what our options are we need to actually go about
+      implementing the solution. It may be the case that existing VFS solutions
+      could be reused with minor changes and thus we could save ourselves a lot of 
+      work. Candidates would be the Netbeans VFS, Suns XFile API or other 
+      available directory APIs (like JNDI). If none of them suit then we will need 
+      to write our own layer.
+    </p>
+  </blockquote>
+  <h3>Naming</h3>
+  <a name="naming" />
+  <blockquote>
+    <p>
+      Currently Ant has a mixture of tasks from various stages it's evolution, with different
+      authors and each utilizing different naming patterns. Some tasks use names such as
+      "src" and "dest" while others use "file" and "tofile". It would be preferrable if 
+      consistent naming patterns were used. It is recomended that we come up with a "best
+      practices" document to document our recomended naming patterns.
+    </p>
+    <p>
+      Before we can come up with such a document we need to identify common patterns through
+      out the tasks. Several tasks have the notion of transforming input from a "source"
+      to a "destination". So we should have consistent naming schemes for these attributes and 
+      elements. Analysis of existing tasks will likely bring out other similar patterns. Once
+      we have identified and documented these similarities then we can establish conventions.
+    </p>
+  </blockquote>
+  <h3>Selector API</h3>
+  <a name="selector" />
+  <blockquote>
+    <p>
+      Currently our filesets allow us to select a set of files based on name patterns.
+      For instance we could create a set of all the files that end with ".java". However
+      there are cases when you wish to select files based on their other attributes, such as 
+      if they are read only or if they are older than a specified date etc.
+    </p>
+    <p>
+      The selector API is one such mechanism to do this. The selector API will allow you to 
+      build file sets based on criteria other than name. Some possible criteria would be
+    </p>
+    <ul>
+      <li>Is the file readable?</li> 
+      <li>Is the file writeable?</li> 
+      <li>What date was the file modified on?</li> 
+      <li>What size is the file?</li> 
+      <li>Does the contents contain the string "magic"?</li> 
+    </ul>
+    <p>
+      If we end up supporting a VFS then we could expand the number of selectors 
+      considerably. A mock representation that has been proposed before is the following. 
+      Of course this is subject to change as soon as someone wants to tackle this action ;)
+    </p>
+ &lt;include&gt;
+   &lt;selector type="name" value="**/*.java"/&gt;
+   &lt;selector type="permission" value="r"/&gt;
+   &lt;!-- could optionally be directory/or some other system specific features --&gt;
+   &lt;selector type="type" value="file"/&gt; 
+   &lt;selector type="modify-time" 
+             operation="greater-than" 
+             value="29th Feb 2003"/&gt;
+ &lt;/include&gt;
+  </blockquote>
+  <h3>Coloring API</h3>
+  <a name="coloring" />
+  <blockquote>
+    <p>
+      When you execute a task such as "javac" there is two types of dependency information
+      that is important to analyze before we determine if we need to recompile a file. Say
+      we are compiling <code></code>, it may depend on the <code></code>
+      file. We call this "structural" dependency information - the structure of the source file 
+      determines what other files it depend upon. However there is also "environmental" 
+      dependency information. For instance if the <code></code> file was compiled with 
+      <code>debug="true"</code> last run and this time needs to be compiled with 
+      <code>debug="false"</code> then it is out of date and needs to be recompiled. We call this 
+      "environmental" dependency information "coloring".
+    </p>
+    <p>
+      So we need to create an infrastructure that allows tasks to manage "coloring". So a task
+      should be able to add coloring information for each resource processed. When the task
+      comes to process the resource again it will detect if the coloring has changed and if it
+      has will force a recompile.
+    </p>
+    <p>
+      An API for such a bean has yet to be established but an example API would be.
+    </p>
+    <pre>
+ColoringManager cm = ...;
+cm.addColor( "debug", "true" );
+cm.addColor( "optimize", "false" );
+cm.setFileSet( myFileSet );
+File[] files = cm.getOutOfDate();
+    </pre>
+  </blockquote>
+  <h3>Structural Dependency Utils</h3>
+  <a name="structural" />
+  <blockquote>
+    <p>
+      In the present ant, it is required that each task manage dependency separately. 
+      This makes it a lot of work to implement even simple dependency checking. To this
+      day many of the core tasks do not implement it correctly. I am specifically
+      talking about "structural" dependency information. The main reason is that it is
+      painful to implement.
+    </p>
+    <p>
+      Some tasks do no dependency checking and will recompile/transform/etc everytime. 
+      Others may perform a simple dependency checking (ie if source file is newer than 
+      destination file then recompile). Ideally a dependency system would actually
+      calculate the dependencies correctly. So we need to have some mechanism to determine
+      that <code>foo.c</code> actually depends upon <code>foo.h</code>, <code>bar.h</code> 
+      and <code>baz.h</code>. As this information is particular to each different task
+      we need to allow tasks to implement this behaviour. Possibly by supplying an interface
+      of the form;
+    </p>
+    <pre>
+public interface DependencyGenerator
+  File[] generateDependencies( File file );
+    </pre>
+    <p>
+      Generating the dependency information is a costly operation and thus we do not want to
+      be doing it everytime you run ant. We want to generate it on the initial build and then 
+      persist somewhere. Everytime a file is out of date, it's dependency information would
+      be regenerated and stored in the dependency cache. Ideally this cache would also store the
+      above mentioned coloring information. So the entry for <code>foo.c</code> may declare that 
+      it is dependent upon <code>foo.h</code>, <code>bar.h</code> and <code>baz.h</code>, aswell 
+      as being compiled with -O2 flag. If any of the dependencies have changed or are out of date 
+      then foo.c would need to be recompiled.
+    </p>
+    <p>
+      A possible API would be
+    </p>
+    <pre>
+DependencyManager dm = ...;
+dm.setFileSet( myFileSet );
+dm.setDependencyCache( myDependencyCacheFile );
+File[] files = cm.getOutOfDate();
+    </pre>
+  </blockquote>
+  <h3>Refactor &lt;exec&gt; infrastructure into Beans</h3>
+  <a name="exec" />
+  <blockquote>
+    <p>
+      Exec and its related classes have currently evolved through several iterations and thus
+      it is not as cleanly designed and as reusable as it could be. Someone needs to pull apart
+      exec and analyze which parts can be turned into JavaBeans and decouple them from the Ant 
+      infrastructure. Once that is done it will make these beans much easier to reuse from other
+      tasks without relying on gaining access to the other task instance.
+    </p>
+  </blockquote>
+  <h3>Refactor &lt;java&gt; infrastructure into Beans</h3>
+  <a name="java" />
+  <blockquote>
+    <p>
+      Much like Exec should be decoupled from Ant runtime, so should classes to implement java 
+      task for the same benefits.
+    </p>
+  </blockquote>
+  <h3>Generic Task Facades</h3>
+  <a name="facade" />
+  <blockquote>
+    <p>
+      Currently we have a few tasks that have multiple implementations. For instance Javac task
+      can actually call jikes, jvc, classic javac or modern javac. Similar things will be seen
+      with the jspc task and the cc task (if it ever gets written). We need to examine this 
+      pattern and see if there is a way to generalize this and make it easier to write such tasks.
+    </p>
+  </blockquote>
+  <h3>Task Packaging</h3>
+  <a name="packaging" />
+  <blockquote>
+    <p>
+      We have already decided that we are going to package Ant tasks in separate jars and
+      have some sort of descriptor that to describe the contents of the jar. However we have 
+      not yet decided how we will break up the tasks. Do we break up the tasks up into 
+      related tasks or into groups that ar elikely to be used together or what? A possible
+      breakdown would be
+    </p>
+    <ul>
+      <li>jdk tasks: javac, javadoc, rmic etc</li>
+      <li>text tasks: regex replace, fixcrlf etc</li>
+      <li>unix tasks: chmod, etc</li>
+      <li>file tasks: copy, move, etc</li>
+    </ul>
+  </blockquote>
+  <h3>Mapping File Attributes during transformation</h3>
+  <a name="mapperext" />
+  <blockquote>
+    <p>
+      When we are copying files from one location to another it is currently possible
+      to rename them using a mapper. So we could rename <code></code> to 
+      <code></code>. On occasion it is useful to modify file attributes
+      other than its name in such operations. So we could copy the files to another
+      location and make them read-only in one operation.
+    </p>
+  </blockquote>
+  <h3>Filters extensions</h3>
+  <a name="filters" />
+  <blockquote>
+    <p>
+      This is partially related to the above action. Filters could be seen as a way 
+      to modify the content attribute of a file during a copy/move. It would be 
+      preferrable if filtering could be abstracted to use <code>FilteredOutputStream</code>s
+      to perform the content modification. That way new Filter types could be constructed
+      and used during file copy (ie an example would be a Perl FilterOutputStream that 
+      allowed you to use perl expressions to transform input).
+    </p>
+  </blockquote>
+  <h3>XML Catalog to load XML Fragments</h3>
+  <a name="catalog" />
+  <blockquote>
+    <p>
+      When including fragments of XML we are currently forced to use relative paths.
+      However this is sometimes undesirable when a single fragment needs to be used
+      across several projects in several different locations. Instead we could use
+      a Catalog to name the fragment and then each developer would only need to install
+      the fragment once and it would be accessible from all the projects.
+    </p>
+  </blockquote>
+  <h3>i18n the Runtime and tasks</h3>
+  <a name="i18n" />
+  <blockquote>
+    <p>
+      Look at the feasability of performing i18n on Ant runtime and core tasks. Look at
+      how much work it will be and how useful it would be. Look at utilizing i18n from 
+      existing projects such as Avalon.
+    </p>
+  </blockquote>
+  <h3>Embeddor API for Ant</h3>
+  <a name="embeddor" />
+  <blockquote>
+    <p>
+      Identify different environments in which it would be useful to embed Ant or an Ant-like 
+      tool. Identify what these environments are likely to demand in terms of API and support
+      and then design a system that works in these environments without compromising ants 
+      core goal (ie a build system). Some suggestions for such an API include;
+    </p>
+    <ul>
+      <li>Pluggable ProjectBuilders to allow building of project from a variety of sources,
+       file, URL, InputStream, SAX etc</li>
+      <li>Pluggable ClassLoader arrangement</li>
+      <li>Ability to set User Properties</li>
+      <li>Ability to add Task/Data/Type definitions</li>
+      <li>Ability to add/remove Listeners</li>
+      <li>Ability to add/remove Loggers</li>
+      <li>Ability to get meta-information about targets (such as name and description)</li>
+      <li>The ability to execute a task and/or targets</li>
+      <li>The ability to add tasklibs</li>
+      <li>The ability to add VFS mount points</li>
+      <li>The ability to manipulate ProjectModel and build it from GUIs</li>
+      <li>A general task engine API</li>
+    </ul>
+  </blockquote>
+  <h3>TypeInfo system</h3>
+  <a name="info" />
+  <blockquote>
+    <p>
+      Add in the ability to represent tasks using specified meta-info, This would allow 
+      generation and manipulation of information such as what attributes are available, 
+      what elements are supported etc. 
+    </p>
+  </blockquote>
+  <h3>Antdoc</h3>
+  <a name="antdoc" />
+  <blockquote>
+    <p>
+      This is partially based on the above TypeInfo system. It involves the ability to 
+      take the TypeInfo made available and generate documentation for the tasks. This 
+      would allow multiple formats of documentaiton to be easily maintained and reduce 
+      the chance that documentation gets out of whack.
+    </p>
+  </blockquote>
+  </body>

Propchange: ant/site/generated/ant2/actionlist.html
    svn:eol-style = native

Added: ant/site/generated/ant2/features.html
--- ant/site/generated/ant2/features.html (added)
+++ ant/site/generated/ant2/features.html Fri Sep  1 14:41:40 2006
@@ -0,0 +1,369 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+  <head>
+    <meta http-equiv="Content-Language" content="en-us">
+    <title>Ant2 feature list</title>
+      <style type="text/css">
+        .comment {
+          COLOR: #900000;
+	  BACKGROUND: #ffa;
+        }
+      </style>
+  </head>
+  <body bgcolor="#FFFFFF">
+    <p class="comment">If something looks like this, this is either a
+    request for input or a &quot;REVISIT&quot; marker or similar.</p>
+    <h1>Ant2 Goals</h1>
+    <p>Even though Ant2 is expected to be incompatible with the
+    current Ant1 series, it still has the same goals. Ant is a Java
+    based build tool and this remains the main focus of it. The
+    original goals of simplicity, understandability and extensibility
+    still stand and Ant2 will try to achieve them even better than
+    Ant1 does.</p>
+    <h2>Simplicity and Understandability</h2>
+    <p>These two goals are closely related. Ant build files shall be
+    easy to read and understand - at the same time it should be easy
+    to write a custom Ant task and to use the utility classes that
+    Ant2 provides.</p>
+    <p>Ant2 shall be more consistent than Ant1 is - this means:</p>
+    <ul>
+      <li>core tasks will use the same attribute names for common
+      functionality</li>
+      <li>similar tasks will be unified to use similar forms.</li>
+      <li>different implementations for the same functionality will be
+      hidden behind facade tasks.</li>
+      <li>properties and data types will be unified so that they share
+      the same namespace and inheritance rules. <i
+      class="comment">Need to talk about how ${} expansion works for
+      filesets and so on.</i></li>
+    </ul>
+    <p>Furthermore some things will have to become more explicit:</p>
+    <ul>
+      <li>remove all magic properties</li>
+      <li>make build file writers explicitly state which
+      filters/filtersets a copy task will use</li>
+      <li>add scoping rules for properties so that not all of them
+      will be inherited by sub-builds, only those that have been
+      specified explicitly. <i class="comment">Fill in details once
+      they've been sorted out.</i></li>
+    </ul>
+    <p>The front-ends for Ant2 shall be smart enough to automatically
+    detect the required libraries (like <code>tools.jar</code>), the
+    use of native scripts shall be kept to a minimum.</p>
+    <p>Build file writers can attach a message to targets that will be
+    presented to the user if that target is going to be skipped (based
+    on the if/unless attribute of the target).</p>
+    <p>Even though Ant installation already is quite simple in Ant1
+    (extract the archive and set two environment variables),
+    alternative ways to install Ant like using 
+    <a href="">Webstart</a> or
+    a "self-extracting" JAR file will be explored.</p>
+    <h2>Extensibility</h2>
+    <p>Ant2 like Ant1 uses build files written in XML as its main
+    input, but it will not be restricted to it. The core of Ant2 will
+    work on an object model of Project/Target/Task that is independent
+    of any external representation.</p> 
+    <p>As an extension of the current <code>&lt;taskdef&gt;</code>
+    concept, tasks can be bundled into task libraries (together with
+    data types and other utility classes). These task libraries are
+    special JAR archives that somehow describe the contained tasks to
+    Ant. Ant will automatically know all tasks contained in task
+    libraries that have been placed into a special directory - in
+    addition task libraries can be referenced and used in a build file
+    explicitly. <i class="comment">Fill in details once they've been
+    sorted out.</i></p>
+    <p>It has become apparent, that several &quot;aspects&quot; of
+    tasks are so common that task writers find themselves duplicating
+    code all over again - things like classpath handling or &quot;do
+    we stop the build if this task fails?&quot; functionality for
+    example. Ant2 will provide a way to let the user attach an
+    &quot;aspect handler&quot; to a project - all attributes that live
+    in a certain namespace are going to be passed to this handler. <i
+    class="comment">Need to talk about TaskContext here.</i></p>
+    <p>Ant2 will farm out common functionality from tasks into utility
+    classes so that task writers can benefit from a tested and stable
+    framework - they shouldn't need to deal with existing tasks
+    directly (like some tasks &quot;abuse&quot; the
+    <code>&lt;touch&gt;</code> task in Ant1).</p>
+    <p>Ant2 will provide a way to define tasks that itself can have
+    tasks as child elements without knowing all defined tasks at
+    compile time.  Discussions on ant-dev usually talk about
+    &quot;container tasks&quot; in this context.</p>
+    <p>The only way to &quot;include&quot; common XML snippets so far
+    has been the usage of external SYSTEM entities, a mechanism that
+    is tied to DTDs and doesn't mix well with alternative
+    approaches like XML Schema.  Ant2 will provide a built-in include
+    mechanism.</p>
+    <h1>New/Modified Features</h1>
+    <p>Ant2 will run the build process fully dynamically, which means
+    that task won't be instantiated before they are actually being run
+    and <code>${}</code> expansion will see the very latest value of a
+    property. It will be possible to reassign values of properties via
+    a built-in task.</p>
+    <h2>Compatibility with Ant1</h2>
+    <p>Ant2 is going to break Ant1 in several ways:</p>
+    <ul>
+      <li>Tasks written for Ant1 won't work in Ant2 as the API of
+      Ant's core and the names of utility classes are going to
+      change. There will probably be adaptors and utility classes to
+      ease the transition for task writers.</li>
+      <li>Build files written for Ant1 will probably not be valid in
+      Ant2 or at least not yield the same results. It is expected that
+      Ant2 will come with a tool to translate Ant1 build files into
+      equivalent Ant2 versions</li>
+      <li>magic properties like <code>build.compiler</code> may
+      disappear and be replaced by a different customization
+      concept.</li>
+      <li>Ant2 is going to require a JDK version 1.2 or above and a
+      JAXP compliant parser version 1.1 or above.</li>
+      <li>If you specify more than one target in another target's
+      depends attribute, Ant1 will execute these targets from left to
+      right (as long as the dependency tree permits it) - Ant2 will
+      not guarantee this behavior but will allow build file writers to
+      specify the order explicitly.</li>
+      <li>Dereferencing a non existent property a via ${a} will result
+      in a build failure.</li>
+    </ul>
+    <h2>Support Integration of Ant Into Other Tools</h2>
+    <p>Ant2 will have a clear separation between the front-end that is
+    responsible for user interactions, the object model that
+    represents the project to build and the part of Ant that runs the
+    build process itself <i class="comment">Name that TaskEngine,
+    ProjectEngine, ExecutionEngine or what?</i>. This separation is
+    expected to ease the integration of Ant (or parts of it) into
+    other products.</p>
+    <p>Ant2 itself will include a command line front-end and Antidote
+    will become the GUI front-end to it. Other front-ends like a
+    servlet front-end are expected <i class="comment">outside of
+    Ant's core</i> as well.</p>
+    <p>In addition to this separation, the following features should
+    help people who want to integrate Ant into their products:</p>
+    <ul>
+      <li>It will be possible to cancel a running build process.</li>
+      <li>Ant will detach from <code>System.err/.out/.in</code>
+      completely and communicate with the front-end via a well defined
+      API.  The front-end will have to handle user input for tasks
+      that need it (tasks that ask for a password for example).</li>
+      <li>Tasks will provide some way to identify their attributes
+      from the outside. <i class="default">fill in details</i></li>
+    </ul>
+    <h2>More Control for Users and Build File Writers</h2>
+    <p>Ant2 will use a <code>BuildListener</code> concept similar to
+    the one of Ant1 but may provide a richer set of events. It will be
+    possible to attach and detach listeners to a build process from
+    within the build file and to modify the behavior of attached
+    listeners.</p>
+    <p>In Ant1 users have little control over how things work.  There
+    are a couple of magic properties to make Ant chose a preferred
+    compiler or modify the CLASSPATH, but they are barely documented.
+    If users want to set these properties for every build process,
+    they have to learn the undocumented tricks of the
+    <code>ANT_OPTS</code> environment variable or the
+    <code>~/.antrc</code> file.</p>
+    <p>Ant2 will have a well defined system to specify user
+    preferences.  This system will not only let user chose their
+    compiler but also give them a chance to provide default values for
+    attributes (say you always want the <code>debug</code> attribute
+    of the <code>javac</code> task to be true - unless it has been
+    disabled explicitly). <i class="comment">Need to give details once
+    they've been sorted out.</i></p>
+    <h2>Documentation System</h2>
+    <p>All tasks will be documented in XML files using a common DTD <i
+    class="comment">Still need to define it</i> - task libraries are
+    expected to include the documentation using this DTD inside the
+    library itself.</p>
+    <h2>Better Subbuild Handling</h2>
+    <p class="comment">Is there something beyond &quot;should become
+    better&quot; right now?</p>
+    <h2>Data Types</h2>
+    <p>Ant1 supports a limited set of data types (fileset, patternset
+    and path) and at least up to Ant 1.3 it is not possible to
+    register custom data types without writing a task that does this.
+    Ant2 will provide a built-in mechanism to define new data
+    types.</p>
+    <p>Existing data-types will be improved, the files in a fileset
+    can be chosen based on more than just pattern matching for example
+    (modification time or permissions for example).  Ant2 will have
+    built-in tasks for set operations.</p>
+    <p>Data types and properties will share the same name space and
+    follow the same scoping and precedence rules. 
+    <i class="comment">${} again.</i></p>
+    <h2>Multi-Threading of Tasks Within a Target</h2>
+    <p>It will be possible to run several tasks in parallel - these
+    tasks will belong to the same target and all tasks will be joined
+    at the end of the target.</p>
+    <h2>Internationalization</h2>
+    <p>Ant2 itself will provide internationalized (error) messages and
+    provide utility classes to help task writers to do the same.  
+    <i class="comment">These utility classes may very well come from a
+    different (Jakarta) project</i>.</p>
+    <p>Ant's primary language and the language of the build file
+    will continue to be English.</p>
+    <h1>Rejected Features</h1>
+    <p>This is list is not complete, it just highlights some of the
+    rejected features and tries to explain why they've been
+    rejected.  Two very common reasons to reject something were, that
+    the request has been too vague or the same functionality could
+    already be provided by some other accepted new feature.</p>
+    <p>For a complete listing of all requested features, see <a
+    href="requested-features.html">requested-features.html</a>. The
+    discussion on all topics can be followed in the <a
+    href="">archives
+    for ant-dev</a> in threads starting from 2001-03-21 - the subject
+    lines contained either <code>[VOTE]</code> or
+    <code>[DISC]</code>.</p>
+    <h2>Simple Flow-Control</h2>
+    <p>People asking for these kind of things have often heard the
+    standard "Ant shall not become yet another scripting language, Ant
+    shall not fall into the same traps make/Perl did ..." response
+    from the committers and some long-term ant-dev people.</p>
+    <p>The long version of that answer is:</p>
+    <ul>
+      <li>There are lots of open source scripting languages, there is
+      no need to define a new one.</li>
+      <li>Ant has been created to be a build tool.  While you can use
+      it for a whole lot of other things, this is not Ant's primary
+      focus (and it shouldn't be).  Most use-cases that ask for
+      flow-control are out of Ant's scope.</li>
+      <li>Ant already provides the requested functionality for many
+      common situations.  The execon and apply tasks can be used to
+      iterate over a set of files as the (planed for Ant2) javaon and
+      anton tasks will do.</li>
+      <li>Providing flow-control inside Ant's core would increase the
+      complexity of this core.  This would make it difficult for new
+      contributors to understand how Ant works and increase the
+      maintenance cost for Ant at the same time.  The goal of the Ant
+      developers is to push as much complexity and functionality out
+      of Ant's core into the tasks as possible.</li>
+    </ul>
+    <p>That being said, Ant2 will make it easy to write iteration or
+    conditional tasks via the new container task concept.  We expect
+    foreach, switch and if tasks to be written, but they will probably
+    not become core parts of the Ant distribution.</p>
+    <h2>Advanced Conditionals for if/unless Attributes</h2>
+    <p>The argument here is the same as for flow-control.  We are
+    talking about complexity that can be pushed from the core to tasks
+    - and that is what will be done.  Instead of additional power for
+    the if/unless attributes, Ant2 will have a new task that can set
+    properties based on the values of other properties or logical
+    combinations of other conditions, something like (making up
+    syntax):</p>
+&lt;condition name=&quot;javamail-complete&quot;&gt;
+  &lt;and&gt;
+    &lt;available class=&quot;javax.mail.Transport&quot;/&gt;
+    &lt;available class=&quot;javax.activation.DataHandler&quot;/&gt;
+  &lt;/and&gt;
+    <p>will become possible</p>
+    <h2>Multi-Threaded Execution of Targets</h2>
+    <p>The general feeling was, that the combination of target
+    dependencies and multi-threading would soon become too complex,
+    especially since Ant2 will allow people to explicitly enforce the
+    order in which (independent) targets will be executed.</p>
+    <p>This issue will be explored again later, it has not been
+    rejected for all time being, but it is out of scope for
+    Ant&nbsp;2.0</p>
+    <h1>Ideas for New Tasks and Tools</h1>
+    <p>Please refer to <a
+    href="requested-features.html">requested-features.html</a> in the
+    section &quot;I. Things that don't affect the core but are
+    requests for new tasks or enhancements to existing tasks.&quot;
+    for this.</p>
+    <hr>
+      <p align="center">$Id: features.html 269844 2001-10-31 07:59:07Z bodewig $</p>
+      <p align="center">Copyright &copy; 2001 Apache Software
+        Foundation. All rights Reserved.</p>
+  </body>

Propchange: ant/site/generated/ant2/features.html
    svn:eol-style = native

Added: ant/site/generated/ant2/original-specification.html
--- ant/site/generated/ant2/original-specification.html (added)
+++ ant/site/generated/ant2/original-specification.html Fri Sep  1 14:41:40 2006
@@ -0,0 +1,278 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "strict.dtd">
+  <HEAD> 
+	 <TITLE>Ant Specification, version 0.5</TITLE> 
+  </HEAD> 
+  <BODY> 
+	 <H1>Ant Specification</H1> 
+	 <P>Version 0.5 (2000/04/20)</P> 
+	 <P>This document specifies the behavior of Ant. At this time, this is a
+		working document with no implementation. It is hoped that this specification
+		will lead to a simplier and more consistent implementation of Ant.</P> 
+	 <P>This document is not intended to be used as an end user manual or user
+		guide to Ant. To adequatly explain the concepts herein in a way appropriate to
+		such a use would potentially complicate this document.</P> 
+	 <H2>Design Goals</H2> 
+	 <P>The following are the overall design goals of Ant:</P> 
+	 <UL> 
+		<LI>Simplicity</LI> 
+		<LI>Understandability</LI> 
+		<LI>Extensibility</LI> 
+	 </UL> 
+	 <H3>Simplicity</H3> 
+	 <P>Ant must be simple to use. Of course, as the definition of simple varies
+		according to the audience of the program. For Ant, since it is a build tool
+		aimed at programmers, the goal is to be simple to use for a competent
+		programmer.</P> 
+	 <H3>Understandability</H3> 
+	 <P>Ant must be clearly understandible for a first time as well as a veteran
+		user. This means that a new user should be able to use Ant comfortably the
+		first time and understand how to modify a build file by looking at it. And it
+		should not require much experience with Ant to understand how it works and how
+		to configure it for particular situtations.</P> 
+	 <H3>Extensibility</H3> 
+	 <P>Ant must be easy to extend. The API used to extend Ant must be easy to
+		use and the way in which these extensions are located and used by the core
+		runtime should be clear.</P> 
+	 <H2>Conceptual Overview</H2> 
+	 <P>This is a conceptual overview of the components used by Ant. Full APIs
+		will be defined later.</P> 
+	 <H3>Project</H3> 
+	 <P>The base unit of work in Ant is the <STRONG>Project</STRONG>. A Project
+		is defined by an editable text file and is represented by an object of type
+		<CODE>org.apache.ant.Project</CODE> at runtime.</P> 
+	 <P>A Project is a collection of <STRONG>Properties</STRONG> and
+		<STRONG>Targets</STRONG>.</P> 
+	 <H3>Properties</H3> 
+	 <P>Properties are mutable name-value pairs that are scoped to the Project
+		and held in a table. Only one pair is allowed per name. It is anticipated that
+		this data structure would be of type <CODE>java.util.Properties</CODE> or a type that has approximatly
+		the same contract.</P> 
+	 <P>Properties can be defined in a hierarchical manner. The order of
+		precidence in this hiearchy is:</P> 
+	 <UL> 
+		<LI>Properties defined on the command line or via a GUI tool</LI> 
+		<LI>Properties defined in the text file which defines the project.</LI> 
+		<LI>Properties defined in a file in the users <CODE>user.home</CODE> directory</LI> 
+		<LI>Properties defined in the installation directory that can be shared
+		  by multiple users.</LI> 
+	 </UL> 
+	 <P>Note: The current version of Ant allows the System property list to be
+		consulted for a return value if the property list doesn't satisfy the requested
+		property name. As all Java code has access to the system property list via the
+		<CODE>java.lang.System</CODE> class, this functionality is considered to be confusing and to be
+		removed.</P> 
+	 <P>Note: The current version of Ant allows property substitution to be
+		performed in the project file. This functionality is being removed.</P> 
+	 <H3>Targets</H3> 
+	 <P>Targets are ordered collections of <STRONG>Tasks</STRONG>, units of work
+		to be performed if a Target is executed. </P> 
+	 <P>Targets can define dependancies on other Targets within the Project. If
+		a Target is deemed to be executed, either directly on the command line, or via
+		a dependancy from some other Target, then all of its dependencies must first be
+		executed. Circular depenancies are resolved by examination of the dependancy
+		stack when a Target is evaluated. If a dependancy is already on the stack of
+		targets to be executed, then the dependancy is considered to have been
+		satisfied.</P> 
+	 <P>After all dependancies of a Target have been satisfied, all of the Tasks
+		contained by the target are configured and executed in sequential order. </P> 
+	 <H3>Tasks</H3> 
+	 <P>A Task is a unit of work. When a Task is to be executed, an instance of
+		the class that defines the behavior of the particular task specified is
+		instantiated and then configured. This class implements the <CODE>org.apache.ant.Task</CODE> interface.
+		It is then executed so that it may be able to perform its function. It is
+		important to note that this configuration occurs just before execution of the
+		task, and after execution of any previous tasks, so that configuration
+		information that was modified by any other Task can be properly set.</P> 
+	 <P>When a Task is executed, it is provided access to the object
+		representing the Project it is running in allowing it to examine the Property
+		list of the project and access to various methods needed to operate.</P> 
+	 <H2>Task Jar Layout</H2> 
+	 <P>Tasks are defined within Java Archive files. The name of the JAR
+		determines the name under which the task is known by in the system. For
+		example, if a Task JAR is named mvdir.jar, the task is known to the system as
+		<CODE>&quot;mvdir&quot;</CODE>.</P> 
+	 <P><EM>Question: Should we say that tasks belong in a JAR file with the
+		.tsk extension?</EM></P> 
+	 <P>The class within the Jar file that implements the <CODE>org.apache.ant.Task</CODE> interface is
+		specified by a manifest attribute named <CODE>Ant-Task-Class</CODE> in the Jar manifest. An example
+		manifest would look like:</P> 
+	 <PRE>    Manifest-Version: 1.0
+    Ant-Task-Class: org.apache.ant.task.javac.JavacTask</PRE> 
+	 <P>When the task is used by Ant, a class loader is created that reads
+		classes from the JAR file. This ensures that there is no chance of namespace
+		collision in the classes of various task JAR files.</P> 
+	 <H2>Installation</H2> 
+	 <P>When Ant is installed on a user system, it installs a directory
+		structure with the following form:</P> 
+	 <PRE>&lt;installdir&gt;/ant      (unix shell script)
+            /ant.bat
+            /ant.jar
+            /
+            /tasks/[task jar files]
+            /docs/[documentation]
+            /README</PRE> 
+	 <P>Note: Current Jakarta practice is to name the Unix shell script with a
+		.sh extension. This goes against Unix conventions and is unecessary. Testing
+		has shown that the leaving the extension off on Unix will not interfere with
+		the working of the Windows batch file.</P>
+	 <P>Note: The ant.jar file has been moved from the lib/ directory and placed
+		alongside the shell startup scripts (which have also been moved out of the bin/
+		directory). This is because on windows platforms, the .jar file is an
+		executable file of sorts.</P> 
+	 <H3>Ant Properties</H3> 
+	 <P>The <CODE></CODE> file contains a list of all the properties that should be
+		set by default when ant is run. In addition there are a few special properties
+		that are used directly by ant. An example of these properties in use is:</P> 
+	 <PRE>    system.taskdir=tasks/
+    user.taskdir=anttasks/</PRE> 
+	 <P>The <CODE>system.taskdir</CODE> property sets where the system looks for Java ARchive files
+		containing tasks. If this property defines a relative path, then the path is
+		taken as relative from the installation directory.</P> 
+	 <P>The <CODE>user.taskdir</CODE> property defines where users can locate Java Archive files
+		containing tasks. If this property defines a realtive path, then the path is
+		taken as relative from the users home directory (as defined by the <CODE>user.home</CODE>
+		system property). Task JAR files in this directory take precendence of those in
+		the system directory.</P>
+	 <P>Note: <EM>It has been suggested to add a properties file hook to the
+		command line to roll in props. Pending investigation.</EM></P> 
+	 <H3>User Preferences</H3> 
+	 <P>In addition to the Ant installation directory, an <CODE></CODE> file can be
+		located in the user's home directory (as found by the system property <CODE>user.home</CODE>)
+		which can define user preferences such as the location of a user tasks
+		directory. Properties defined in this file take precidence over those set in
+		the installation's <CODE></CODE> file. Such a file could look like:</P> 
+	 <PRE>    user.taskdir=anttasks/
+    javac.debug=off</PRE> 
+	 <P>Properties starting with <CODE>&quot;system.&quot;</CODE> in the user's <CODE></CODE> file are not
+		allowed and must cause a warning to be thrown.</P> 
+	 <H2>Project Configuration</H2> 
+	 <P>Ant's Project text file is structured using XML and reflects the
+		structure of the various components described in the Conceptual Overview.</P> 
+	 <P>A sample Project file:</P> 
+	 <PRE>&lt;project name=&quot;projectname&quot; defaulttarget=&quot;main&quot; taskdir=&quot;tasks/&quot;&gt;
+  &lt;property name=&quot;javac.debug&quot; value=&quot;on&quot;/&gt;
+  &lt;target name=&quot;main&quot;&gt;
+    &lt;taskimpl ...&gt;
+       ...
+    &lt;/taskimpl&gt;
+  &lt;/target&gt;
+	 <H3>The Project Element</H3> 
+	 <P>The <CODE>project</CODE> element has the following required attributes:</P> 
+	 <UL> 
+		<LI><CODE><STRONG>defaulttarget</STRONG></CODE> defining the default target to be executed if no other target
+		  is specified when Ant is run</LI> 
+	 </UL> 
+	 <P>It also has the following optional allowed attributes:</P> 
+	 <UL> 
+		<LI><CODE><CODE><STRONG>name</STRONG></CODE></CODE> defining a name for this project</LI> 
+		<LI><CODE><STRONG>taskdir</STRONG></CODE> defining a directory in which project specific tasks can be
+		  located. Tasks in this directory take precedence over those in the either the
+		  user taskdir or the installation taskdir.</LI> 
+	 </UL> 
+	 <P>The following elements are allowed as children of the project
+		element:</P> 
+	 <UL> 
+		<LI><CODE><STRONG>property</STRONG></CODE> defining a property scoped to the project</LI> 
+		<LI><CODE><STRONG>target</STRONG></CODE> defining a target</LI>
+	 </UL>
+	 <H3>The Property Element</H3>
+	 <P>asdf</P>
+	 <H3>The Target Element</H3>
+	 <P>asfd</P> 
+	 <H2>Configuration of Tasks</H2> 
+	 <P>The Task section of the configuration file is structured as such:</P> 
+	 <PRE>  &lt;[taskname] [attname=value] [attname=value]...]&gt;
+    [&lt;[elementname] [attname=value] ...&gt; ... &lt;/[elementname]&gt;]
+  &lt;/[taskname]&gt;</PRE> 
+	 <P>The taskname is used to find the class of the Task. Once the class has
+		been located and an instance of it created, all of the attributes of the Task
+		are reflected into the task instance using bean patterns. For example, if a
+		Task contains an attribute named &quot;directory&quot;, the method named
+		setDirectory would be called with the attribute value cast to the appropriate
+		type desired by the method. <EM>(What to do if the type isn't a file or a
+		simple type, look for the class and see if it has a setString method?)</EM></P>
+	 <P>Text blocks contained by the element are added to task using an addText
+		method. <EM>Place an example...</EM></P> 
+	 <P>For each element contained in the Task definition, an addElementname
+		method is found on the task. The parameter type of the method defines an object
+		that will be loaded and instantiated. The attributes of the element are
+		reflected into the object using bean methods. Any text is set using the addText
+		method. Any elements are recursed in the same fashion.</P>
+	 <P>Search order of tasks.... project/user/system</P> 
+	 <H2>Command Line</H2> 
+	 <P>The command line utility provided with Ant must support the following
+		allowable syntax:</P> 
+	 <P><CODE>ant projectfile [prop=value [prop=value...]] [target]</CODE></P>
+	 <P>Internally, the command line shell scripts should call the <CODE>org.apache.ant.Main</CODE> class
+		with the following arguments:</P>
+	 <PRE>java -Dant.home=installdir org.apache.ant.Main $*</PRE>
+	 <P>or its equivalent on the host platform. Note that the ant installation
+		directory is a System property. The above syntax results in ant.home being
+		placed in the System property list.</P>
+	 <P>Note: <EM>On unix, finding the directory of the script that was launched
+		is relatively easy. However on Windows, I'm not sure the best way of handling
+		this.</EM></P> 
+	 <H2>File Naming Conventions</H2> 
+	 <P>File naming in a cross platform tool is tricky. For maximum portability
+		and understandiblity it is recommended that project files use the following
+		conventions:</P> 
+	 <UL> 
+		<LI>The '/' character is used as a directory seperator</LI> 
+		<LI>The ':' character is used as a path seperator</LI> 
+		<LI>Only relative paths are used</LI> 
+	 </UL> 
+	 <P>However, to allow for maximum flexibility and to allow project authors
+		to use conventions that make sense on their native platform, Ant allows for a
+		representation of file names which has the following rules:</P> 
+	 <UL> 
+		<LI>Directories are seperated by the forward slash ('/') or backwards
+		  slash ('\') character.</LI> 
+		<LI>File names starting with either of the above directory seperators are
+		  considered to be absolute paths.</LI> 
+		<LI>On systems that support multiple file roots (e.g. Windows), a file
+		  name that starts with a single alphabetical character followed by a colon (':')
+		  followed by a directory seperator defines an absolute path where the letter
+		  corresponds with a directory root.</LI> 
+		<LI>File names starting with any other character are considered to be
+		  relative paths. In project files, all relative paths are resolved relative to
+		  the directory in which the project file is located.</LI> 
+	 </UL> 
+	 <P>Absolute paths are not recommended for build files as they reduce the
+		ability to share a project between u sers or machines.</P> 
+	 <P>In situtations where a set of filenames need to be specified, such as
+		defining a classpath, both the colon (':') andsemicolon (';') are allowable
+		characters to seperate each filename. The only case that has to be
+		disambiguated is if a user specifies paths that contain windows style absolute
+		paths. In this case, the colon is not treated as a path seperator if the
+		following rules are met:</P> 
+	 <UL> 
+		<LI>The character two places before the colon is either of the allowable
+		  path seperators (':' or ';') or if the colon is the second character of the
+		  string.</LI> 
+		<LI>The character immediately before the colon is a alphabetic character
+		  in the range a-z or A-Z.</LI> 
+		<LI>The character immediately after the colon is either of the allowable
+		  directory seperators ('/' or '\').</LI> 
+	 </UL> 
+	 <H2>Scripting Model</H2> 
+	 <P>Sam, I'm leaving this to you. </P>
+	 <H2>Runtime Requirements</H2>
+	 <P>The following requirements are system requirements that Ant should have
+		in order to run correctly. We should not bundle in any of these into the
+		distribution of ant.</P>
+	 <UL>
+		<LI>JDK 1.1 or greater</LI>
+		<LI>A JAXP compliant parser on the classpath</LI>
+	 </UL>
+	 <P>Note: <EM>When running on JDK 1.2 or greater, the tools.jar isn't on the
+		classpath by default. There's a few different ways we can take care of this.
+		One is to put it on the classpath in the execute script (I don't like this
+		one). Another is to find the location of tools.jar at runtime and put it on the
+		classpath of class loaders that load in task.jars so that, at least in the
+		scope of the Tasks, the relevant classes are there. </EM></P>
+	 <P></P> 
+	 <P></P> </BODY>

Propchange: ant/site/generated/ant2/original-specification.html
    svn:eol-style = native

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message