diff --git a/proposal/myrmidon/build.xml b/proposal/myrmidon/build.xml index 784ed6788..4307f355d 100644 --- a/proposal/myrmidon/build.xml +++ b/proposal/myrmidon/build.xml @@ -749,26 +749,6 @@ Legal: style="${ant.home}/etc/jdepend-frames.xsl"/> - - - - - - - - - - - - diff --git a/proposal/myrmidon/docs/ant1compat.html b/proposal/myrmidon/docs/ant1compat.html deleted file mode 100644 index 7ea37203f..000000000 --- a/proposal/myrmidon/docs/ant1compat.html +++ /dev/null @@ -1,231 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - Ant 1 Compatibitlity Layer - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Overview - -
-
-

- The Myrmidon-Ant1 Compatibility layer works by reusing most of the Ant 1 code, - with tasks and datatypes - being prefixed with "ant1." in build files. Almost all of the main Ant 1 tree - is included in the compatibility layer antlib. To insulate from changes in - the Ant 1 tree, Ant 1 class files are extracted from a jar, rather than - being compiled from scratch. -

-

- Here's how it works: The first time an Ant 1 task is encountered, an Ant 1 - project is created, and stored in the TaskContext under the name "ant1.project". - The Ant 1 versions of Task and Project have been extended, overriding core behaviour, - with Myrmidon-specific behaviour. -

-

- The updated version of Task implements Configurable, receiving it's - complete Task Model, and actually setting/adding/creating attributes - with the help of the IntrospectionHelper. This process is designed to - mimic the Ant 1 configuration policy, although not all of the - subtle variations of configuration present in Ant 1 are handled. -

-

- The updated version of Project will provide hooks into the Myrmidon TaskContext, - such as:

-
    -
  • logging (done)
    • -
  • properties (done)
    • -
  • references (not yet done)
    • -
  • Task defined by <taskdef> (done)
    • -
-

- So at present, properties declared in Ant 2 tasks are available to all Ant 1 tasks, - and vice-versa. However, while a <ant1.path> reference works fine - in other <ant1.XXX> - tasks, it's not visible to Ant 2 tasks in the same build, and vice-versa. -

-

- The <taskdef> task works ok, registering the task with the TypeManager using the - "ant1." prefix. Only a couple of DataTypes (Path and Patternset) are working - as top-level types, but this should be just a matter of adding references to - the Ant 1 version of TypeInstanceTask in the descriptor. -

-

- The TransformingProjectBuilder (which is now the default builder for files - of type ".xml", applies a transformation stylesheet to the file, prefixing select - tasks (all at present) with "ant.". If a version attribute is encountered, the - file is not transformed -

-
-
- - - -
- - Using the compatibility layer - -
-
- - - -
- - Using Ant 1 tasks in a Myrmidon build file - -
-
-

- If you have a Myrmidon build file (eg with version="2.0" - on the project element, you can use Ant 1 tasks and datatypes by using - the "ant1." suffix on the regular element name. - Virtually all tasks and datatypes from Ant 1.4.1 are available - in this way. -

-

- When declaring a new task using the <ant1.taskdef> - task, don't prepend "ant1." to the taskname. This will be - done automatically by the taskdef task. However, you will need - to use the "ant1." prefix in all uses of that task. -

-
-
- - - -
- - Using an existing Ant 1 build file - -
-
-

- Myrmidon will automatically handle Ant 1 build files using the - Ant 1 Compatibility layer. So, using an Ant 1 build - file with Myrmidon should be as simple as:

- 
[myrmidon-command] -f ant1-build-file.xml
-

- This works as follows: When Myrmidon encounters a ".xml" build file which does not have a - version attribute on the top-level project - element, it assumes that it is an Ant 1 build file. So all tasks are - interpreted as though they are prefixed with the "ant." name prefix. -

-
-
-
-
- - - -
- - Building the compatibility layer - -
-
-

Before building the Ant 1 Compatibility layer, you need to build - Myrmidon, running the dist-lite target of the main build. - See the build instructions - for more details.

-

To build the compatibility layer, simply execute:

- 
ant -f ant1compat.xml
-

from within the root directory of the Myrmidon source tree.

-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/buildfile.html b/proposal/myrmidon/docs/buildfile.html deleted file mode 100644 index 6938633e0..000000000 --- a/proposal/myrmidon/docs/buildfile.html +++ /dev/null @@ -1,685 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - User Guide - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Project File - -
-
-

-A project file is an XML file that describes which tasks to execute, and in -which order to execute them in. A project can be broken up into several steps, -or targets. A target is simply a list of the tasks that need to be -executed to perform the step. A target may also include some dependency -information. Myrmidon makes sure that targets are executed in the correct order, -so that a target is executed before the targets that depend on it.

-

The project file format is very similar to the format used in Ant 1. The -root element of a project file must be a <project> element. -It can take the following attributes: -

- - - - - - - - - - - - - - - - - - - - - - - - - - -
- - Attribute - - - - Description - - - - Default Value - -
- - name - - - - The project name. - - - - The name of the project file, with the extension removed. - -
- - basedir - - - - The base directory for the project. The base directory is used - to resolve all relative file names used in the project file. - - - - - The directory containing the project file. - -
- - default - - - - The name of the default target. - - - - main - -
- - version - - - - The project file format version that the project is written for. - - - - None, must be 2.0 - -
-

-A <project> element can contain the following elements, -in the order given below: -

- - - - -
- - Project References - -
-
-

Project references allow the project to import, or reference, other projects. -A <projectref> element takes the following attributes:

- - - - - - - - - - - - - - - - -
- - Attribute - - - - Description - - - - Default Value - -
- - name - - - - The name to use to identify the referenced project. - - - - Required - -
- - location - - - - The path to the project file to reference. - - - - Required - -
-

-The targets of a referenced project can be used in the depends list -of a target in the referencing project, using the syntax -project-name->target-name. Here is a simple example:

-
- - - - - - - - - - - - - - - - - 
-
-<project version="2.0">
-    <!-- Reference another project -->
-    <projectref name="subproject" location="subproject/build.xml"/>
-
-    <!-- Use the "compile" target from the referenced project -->
-    <target name="main" depends="subproject->compile">
-        .. do some stuff ..
-    </target>
-</project>
-
-
-
-
- - - -
- - Library Imports - -
-
-

Library imports allow the project to import the tasks and data-types from an -antlib. An <import> element takes the following attributes:

- - - - - - - - - - - - - - - - - - - - - -
- - Attribute - - - - Description - - - - Default Value - -
- - library - - - - The name of the library to import. The ext directory - of the Myrmidon distribution is searched for a library file with - the given name, and an atl extension. - - - - Required - -
- - type - - - - The type of definition to import. Values include task, - and data-type. - - - - None - -
- - name - - - - The name of the type to import. - - - - None - -
-

-If the type and name attributes are not provided, -the entire contents of the antlib are imported. -

-

The following example import the <my-task> task from -the my-tasks antlib.

-
- - - - - - - - - - - - - - - - - 
-
-<project version="2.0">
-  <!-- Import task <my-task> from the 'my-tasks' antlib. -->
-  <import library="my-tasks" type="task" name="my-task"/>
-
-  <target name="main">
-     <my-task some-prop=".."/>
-  </target>
-</project>
-
-
-
-
- - - -
- - Initialization Tasks - -
-
-

Initialisation tasks are run before any of the project's targets are run, and -are used to initialise the project. Any task can be used as an initialization -task, including <property> and data-type instances. An example:

-
- - - - - - - - - - - - - - - - - 
-
-<project version="2.0">
-
-  <property name="some-property" value="some value"/>
-  <path id="classpath">
-    <fileset dir="lib"/>
-  </path>
-  <log>Set classpath to ${classpath}</log>
-
-  <target name="main">
-    .. do some stuff ..
-  </target>
-
-</project>
-
-
-
-
- - - -
- - Targets - -
-
-

Targets have a similar format to targets in Ant 1.x, though some of the -behaviour is different. A <target> element takes the -following attributes:

- - - - - - - - - - - - - - - - -
- - Attribute - - - - Description - - - - Default Value - -
- - name - - - - The name of the target. - - - - Required - -
- - depends - - - - A comma-separated list of targets that this target depends on. - This list can contain targets from referenced projects. - - - - None - -
-
-
-
-
- - - -
- - Tasks - -
-
-

- Listed below are some of the current set of tasks. You can find example - usages of these tasks in the sample project file src/make/sample.ant. -

-

<condition>

-

Sets a property if a particular condition is true. See - Conditions for a list of available conditions.

-

<fail>

-

Causes the build to fail.

-

<if>

-

Conditionally executes a set of tasks.

-

<load-properties>

-

Loads a set of properties from a file.

-

<log>

-

Writes a log message.

-

<property>

-

Sets a property.

-

<try-catch>

-

Runs a set of tasks, with a provided error and clean-up handler.

-

<converter-def>

-

Register a type converter. These are used when configuring a task - or data-type from attributes.

-

<type-def>

-

Register a task or data-type.

-

<import>

-

Register the contents of an antlib.

-
-
- - - -
- - Conditions - -
-
-

The following conditions are available

-

<and>

-

Evaluates a set of nested conditions, and AND them together. Evaluation is - lazy. An empty <and> condition evaluates to true.

-

<available>

-

Tests if a particular class or resource is available.

-

<file-test>

-

Tests a file against a set of file selectors.

-

<is-set>

-

Tests whether a proeprty is set, and not set to 'false'.

-

<or>

-

Evaluates a set of nested conditions, and OR them together. Evaluation is - lazy. An empty <or> evaluates to true.

-

<os>

-

Tests which operating system the build is running on.

-

<not>

-

Negates a nested condition.

-
-
- - - -
- - File Name Mappers - -
-
-

The following file name mappers are available:

-

<chain>

-

Applies a set of nested file name mappers to file names.

-

<flatten>

-

Maps all file names to a single directory.

-

<prefix>

-

Adds a prefix to the front of each file name.

-

<map-extension>

-

Changes the extension of file names.

-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/classloader.html b/proposal/myrmidon/docs/classloader.html deleted file mode 100644 index 1e2fe741e..000000000 --- a/proposal/myrmidon/docs/classloader.html +++ /dev/null @@ -1,241 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - On ClassLoaders in Ant 2 - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - ClassLoader Management - -
-
-

In many ways Ant 2 needs to follow rules similar to a number of - different application servers with respect to ClassLoader management. - Ant 2 will create a number of different ClassLoaders that have access - to different sets of resources (and thus Classes). The main reason - for this arrangment is to partition different sections of the - application such as the Container, the Task API, task/type libraries - and support libraries.

-

The recomended structure for ClassLoader relationships is a hierarchy. - When a ClassLoader is asked for a resource (or a class) it first delegates - to it's parent to ask for the resource. If the resource is not present in - its parent ClassLoader then the ClassLoader attempts to locate the resource - in it's own store. In practice this means that all the classes (and static - variables defined by said classes) in a parent ClassLoader are shared with - the child ClassLoaders.

-

Using kooky ascii art, the specific ClassLoader structure for Ant 2 is as - follows:

-
- - - - - - - - - - - - - - - - - 
-                  Bootstrap
-                      |
-                   System
-                      |
-                   Common
-                  /      \
-             Container  Shared
-                         /   \
-                    Antlib1  Antlib2 ...
-
-
-
    -
  • - The - Bootstrap ClassLoader contains the classes and resources - provided by the Java runtime. - -
    • -
  • - The - System ClassLoader contains the classes that were made accessible - via the CLASSPATH environment variable. If the standard ant script was used then this - should only contain the classes that are used to bootstrap the ant runtime. ie - - $ANT_HOME/bin/ant-launcher.jar -
    • -
  • - The - Common ClassLoader contains the classes and resources - that are made visible to both the Container and to all the ant type libraries. This - contains all the classes that the Container uses to communicate with tasks and other - supporting infrastructure. In particular it contains the following APIs; - -
      -
    • - Task API - Contains the classes that are part of the API used - to define tasks. - -
      • -
    • - ProjectListener API - Contains the classes necessary to define new - ProjectListeners. - -
      • -
    • - Aspect API - Contains the classes that are used to define Aspects - of the container. - -
      • -
    • - Container API - Contains the interfaces that are required to communicate - with the objects deep within the container. - NOTE: These interfaces - are not to be used by user tasks but are made available so that certain tasks (such - as <antcall/>) can be implemented. However they are subject to change without - notice between between different Ant 2 versions. - -
      • -
    -

    - These classes are loaded from all the jars present in the - $ANT_HOME/lib - directory. - -

    -
    • -
  • - The - Container ClassLoader contains all the classes and resources - that are part of the actual implementation of the Container. These classes are not - directly accessible to any Ant library or task. Some of the classes are indirectly - accessible to tasks and other elements defined in the ant libraries as they implement - interfaces defined in the - Common ClassLoader. The classes that are - stored in jars in the - $ANT_HOME/bin/lib/ directory. - -
    • -
  • - The - Shared ClassLoader contains all the classes and resources - that are shared across all of the ant libraries (unless they are als needed by the - container in which case they should be placed int the - Container - ClassLoader). This ClassLoader is populated by all the jars that are contained in - the - $ANT_HOME/shared/ directory. - -
    • -
  • - The - AntLib ClassLoaders each contain the classes and resources - that required by that particular library. Note that in some cases a single Ant - Library will manifest as a single ClassLoader containing a single jar. However - in some cases it is possible for one Ant Library to have multiple jars in its - ClassLoader or even have multiple ClassLoaders. See XXXX for further details. - -
    • -
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/configuring.html b/proposal/myrmidon/docs/configuring.html deleted file mode 100644 index 67e0a7828..000000000 --- a/proposal/myrmidon/docs/configuring.html +++ /dev/null @@ -1,419 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - On Task Configuring in Ant 2 - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Introduction - -
-
-

This section will describe in detail the mechanism via which tasks are - configured. Configuration is the name given to the stage in tasks - lifecycle via which the XML representation is mapped onto the task - object.

-
-
- - - -
- - Names - -
-
-

When mapping the XML representation on to the task object you - need to be able map the names as they appear in the XML to the - names as they appear in the Java code. The process is for generating - a java name from the xml name is as follows.

-
    -
  1. Capitalize the first character of name.
    2. -
  2. Find any '-' characters in XML name and remove character and - capitalize the following letter. (And there must be a following - letter)
    3. -
-

Some example mappings;

-
- - - - - - - - - - - - - - - - - 
-my-name    ===>   MyName
-aString    ===>   AString
-Basedir    ===>   Basedir
-baseDir    ===>   BaseDir
-url        ===>   Url
-
-

Note that the above transformation is lossy and as such the - following XML names all map to the same Java name. The ant1.x mapping - is similarly lossy and in practice this has not been an issue.

-
- - - - - - - - - - - - - - - - - 
-base-dir   ===>   BaseDir
-Base-dir   ===>   BaseDir
-baseDir    ===>   BaseDir
-BaseDir    ===>   BaseDir
-
-

NOTE: We should really resolve this and either disallow '-' characters - or disallow uppercase or something. (PD)

-
-
- - - -
- - Resolving Values - -
-
-

The first stage of mapping the XML representation to the task - is resolving all text data. The text data that needs to be resolved - include the values of attributes and the content.

-

Resolution consists of expanding any property references in the text - data. Property references are identified as starting with the token - "${" and finishing with another "}" token. The text - in between is the name of a property. The value of the property replaces - the sequence of text starting with the "${" token and finishing - with the "}" token.

-

Note that the value of the property may not be a string. If the text data - contains text (or other property references) to either side of the property - reference then it must be converted to a - String.

-
-
- - - -
- - Modeller - -
-
-

Currently the representation of object are stored in a hierarchial - tree of org.apache.myrmidon.api.metadata.ModelElement - objects. Each ModelElement has a number of attributes and can have - either content or sub-elements.

-

In most cases it is the responsibility of the runtime to map - the ModelElement onto an object. However in some cases it may be useful - for the object to get access to it's own model and for it to explicitly - manage it's own configuration. In this case the object should implement - the org.apache.myrmidon.api.metadata.Modeller interface - which will provide the mechanism for the object to receive its own - representation and configure itself.

-

Note that the Modeller mechanism should be avoided if possible - as it adds considerable complexity to the implementing object.

-
-
- - - -
- - Attributes - -
-
-

To map an XML attribute on to a Java object, the name of the - attribute is mapped to a java name and prefixed with the string - "set". The resulting string is then used to look up a - method with a single parameter.

-

For example, for the attribute "world" would result - in a lookup of a method named "setWorld" with a single - parameter.

-

If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity. Theres is an exception - to this rule that allows 2 methods to be matched if one of the - methods takes a java.lang.String parameter. The method - that has the java.lang.String parameter is ignored and - the other method would be chosen. This exception is allowed as it is - common practice for a task to evolve from String parameters to more - strongly typed parameters.

-

The resolved text data of the attribute must be - converted to the type of the matched - methods parameter. For example, if the "setWorld" method - took a parameter of type java.io.File then the resolved - text data must be converted into a java.io.File. The - conversion is done by the Converter architecture that is more fully - described in the Converter HOWTO.

-

After the value is converted to the correct type the method is - invoked with the converted value.

-
-
- - - -
- - Content - -
-
-

The XML representation of object can have either have nested - elements or nested text (content) but not both. To add the content - to an object a method named "content" with one parameter is looked - up. The resolved text data for content is then - converted to the type of the parameter - and passed in via the method.

-
-
- - - -
- - Element - -
-
-

Mapping an ModelElement onto a java object is a series of steps. - If the ModelElement name ends with the string "-ref" then - it is treated as a reference element - see the Referrenced - Elements section. Otherwise, the element is first attempted to - be mapped as a Named Element and if no match is found via - that method it tries to treat the element as a Typed Element.

- - - -
- - Named Elements - -
-
-

To map a named ModelElement on to a Java object, the name of - the element is mapped to a java name and prefixed with the string - "add". The resulting string is then used to look up a - method with a single parameter.

-

For example, for the attribute "geometry" would result - in a lookup of a method named "addGeometry" with a single - parameter. If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity. If no methods were found that - match name then skip down to configuring "typed" elements.

-

The type of the methods single parameter is then examined to determine - what happens next. There are two valid situations, if neither of these are - satisfied, then an exception is thrown.

-
    -
  • The parameters type is org.apache.myrmidon.api.metadata.ModelElement
    • -
  • The parameters type is a concrete class
    • -
-

1. If the parameter has a type of org.apache.myrmidon.api.metadata.ModelElement - then the un-modified model representation of element is passed to object by invoking - the adder method.

-

2. If the parameters type is concrete then an instance of the parameter is - instantiated using the default constructor. This created object is then configured - in the same manner as task using the elements representation as the model. After - the object is configured it is passed into object by invoking the adder method.

-
-
- - - -
- - Referrenced Elements - -
-
-

A referenced element is one that has a name ending in - "-ref" and has a single attribute "name" - and no content or child elements.

-

The value of the "name" attribute is the name of a property. - The value of this property is retrieved from the TaskContext.

-

Like with Named Elements the name of the element (minus - the "-ref" part) is mapped to a java name and prefixed with the string - "add". The resulting string is then used to look up a - method with a single parameter. If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity.

-

The value retrieved from the TaskContext is then converted to the type - of the methods parameter and the add method is invoked with the converted value.

-

An example usage is the following;

-
- - - - - - - - - - - - - - - - - 
-
-            <my-task ...>
-              <classpath-ref name="project.class.path"/>
-            </my-task>
-
-
-
-
-
- - - -
- - Typed Elements - -
-
-

"Typed" elements can also be added to an object. A typed element - is one in which the name of the element actually refers to a type rather than the - name of the adder to call.

-

For example, you may wish to allow a task to add arbitrary instances of the - Condition role to a task. So instead of adding methods such as - addAnd(AndCondition), addOr(OrCondition) and - addXor(XorCondition) you can instead add a single method - add(Condition). This vastly simplifies the amount of work required - to write tasks that take conditions. More importantly it allows end-users to - extend the number of elements selected by task. For instance if the user wanted - a "nand" condition they could write the Nand type use it in their build - file. For a discussion on roles and types see the Types - HOWTO.

-

To use a Typed adder there must be a single method named "add" that - has a single parameter. The parameter MUST be an abstract interface and - must be registered as a role. The name of the element is then used to lookup the - a type in the TypeManager with a role matching the interface name.

-

For example if an element named "nand" was added to an object that had - an adder with the signature void add( Condition condition ) then - the type named "nand" in the role "Condition" would be looked up. - An instance of the type would then be created using the default constructor and the - created object would be configured and then adder to object using adder.

-
-
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/differences.html b/proposal/myrmidon/docs/differences.html deleted file mode 100644 index 84ec3363b..000000000 --- a/proposal/myrmidon/docs/differences.html +++ /dev/null @@ -1,144 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - Differences to Ant 1 - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Differences to Ant 1.x - -
-
-

Some of the differences between Ant 1.x and Myrmidon:

-
    -
  • - Groups of tasks can be assembled into self-describing - antlib task libraries. This makes it very easy to - distribute and install tasks and data-types. -
    • -
  • A project can import other projects, and reference their targets.
    • -
  • Properties and data type references now share the same namespace.
    • -
  • - Changes to task and data-type API: -
      -
    • An interface based API, through which a task interacts with the - task engine, and the services it provides.
      • -
    • A well-defined object lifecycle.
      • -
    • Polymorphic types are supported when objects are configured.
      • -
    • Reference handling is handled automatically when objects are configured.
      • -
    • Aspects can be used to decorate tasks, to add facilities like logging, - error handling, or user preferences.
      • -
    -
    • -
  • A set of well-defined services and APIs have been introduced, to allow - tasks to do their work without depending on other tasks: -
      -
    • Execute external commands.
      • -
    • Execute other tasks.
      • -
    • Manage ClassLoaders and Class-paths.
      • -
    • Virtual file system (in progress).
      • -
    • Execute Java applications (in progress).
      • -
    • ...
      • -
    -
    • -
-

There are plenty more features planned. You can read about them - here. -

-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/getinvolved.html b/proposal/myrmidon/docs/getinvolved.html deleted file mode 100644 index 56aeda217..000000000 --- a/proposal/myrmidon/docs/getinvolved.html +++ /dev/null @@ -1,121 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - Get Involved - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Get Involved - -
-
-

There are plenty of things you can do to help out with Myrmidon. The - Todo list describes items which still need to - be done. Of course, since this is an open-source project, there's - plenty of scope for experimentation, and you can pretty much make up - your own items to work on.

-

Some things that are worth reading if you do want to get involved:

- -

There is no Ant 2 or Myrmidon mailing list yet, so direct any questions - or comments you have to the ant-dev mailing list.

-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/index.html b/proposal/myrmidon/docs/index.html deleted file mode 100644 index c996b3413..000000000 --- a/proposal/myrmidon/docs/index.html +++ /dev/null @@ -1,187 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - Myrmidon - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - What is Ant? - -
-
-

Ant is a cross-platform build tool that features ease of - use and extensibility as it's primary goal.

-

Why another build tool when there is already make, gnumake, - nmake, jam, and others? Make-like tools are inherently shell-based; - they execute native commands and shell scripts to perform the work - associated with the build process. So to extend the the tool by - writing a program or script executable by the OS you are on. This - makes it difficult to achieve portability between platforms.

-

Ant is a different beast. Instead of using OS-specific commands - to extend the build process, you leverage the cross-platform features - of Java to write "tasks". This makes it much easier to achieve - a portal build process between platforms. Ant also differs in that it uses - XML to describe the build process.

-
-
- - - -
- - What is Myrmidon? - -
-
-

Myrmidon is a proposal for Ant 2. Ant 2 is the next evolution of the - Ant build tool aimed at removing many of the limitations of the Ant 1.x - product. In particular it aims to;

-
    -
  • Remove ambiguities and points of confusion for build file - writers.
    • -
  • Ease deployment and management of 3rd party tasks and - dependencies.
    • -
  • Simplify development of tasks by task-writers.
    • -
  • Enable ad-hoc "tasks" to be written inside build file, - probably using well known scripting languages such as python and - javascript. (Possible in Ant 1.x but prohibitively difficult).
    • -
  • Integrate templating technologies such as XSLT, velocity etc - to enable development of reusable build file elements.
    • -
-

You can read more about the goals of Ant 2 - here. -

-

Myrmidon was specifically designed as both a tool and as - an API library that can be reused in other products. It contains the - basic building blocks for assembling any sort of task-based tool. Ant 2 - is an example of such a tool, which could be assembled using the Myrmidon - task container, and a library of build related tasks. In the future expect - to see Testing frameworks, Job Schedulers (ie Cron managers), shells - and install tools based on the Myrmidon base.

-
-
- - - -
- - A Rose by any other name ... - -
-
-

- The name Myrmidon is a derivation of a mythological name for some ants that were turned - into soldiers by the god Zeus. It came to mean "a subordinate who executes orders - unquestioningly" which seemed suitable for a task execution/build tool. A more complete - description stolen from - - http://bondi-blue.parlez.com/previous_words/myrmidon.txt. -

- - The appellation Myrmidon was derived from the Greek word "myrmex", - meaning ant. According to Greek mythology, the Myrmidons were - transformed into humans by the god Zeus as an act of kindness to his - son Aeacus. King Aeacus, captivated by a colony of ants, prayed - that he should receive an increase in population equal to the - number of ants before him. When he awoke the next day, the ants - were his human subjects. Thereafter, they were known as the - Myrmidons. See "The Iliad" for Homers' account of the Myrmidons - during the Trojan War. - -
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/librarys.html b/proposal/myrmidon/docs/librarys.html deleted file mode 100644 index 235f8bb4b..000000000 --- a/proposal/myrmidon/docs/librarys.html +++ /dev/null @@ -1,356 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - On Libraries in Ant 2 - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Library Management - -
-
-

Long ago there was identified the need for libraries that contain - tasks and other elements present in the build file. This document - attempts to describe the mechanism via which these libraries will be - defined and used in Ant 2. The libraries (also referred to as - deployments) will be termed antlibs.

-

Ant libraries can be packaged and signed into a ANt Type Library - format (.atl) using the standard Java Archive tools. (For details on - the .jar file format see the - - - Jar Specification. -

-

When packaged into such a form the META-INF/ directory contains - ant specific descriptors in addition to the standard Jar manifest - and other descriptor files. The archive will also contain the - - .class files for all the tasks and other types the - library defines. It may also contain additional resources that can - be referenced in the build file (an example being DTDs). -

-

The library may also need access to other libraries or resources - to perform its job. For instance, if the task loaded an XML document - and then processed said document using the - Trax API then - the Ant library needs to have access to the - Trax API and an - implementation of the API. The Antlib mechanism thus uses the standard - "Optional Package" Specification to declare dependencies on other - libraries. -

-

The libraries will usually be installed in standard locations that - make it possible for the Ant container to automatically locate and scan - the libraries. It will also be possible for the users to specify - additional search locations or even the specific location of ant - libraries.

-

The following sections will describe each of these different facets - in greater detail.

- - - -
- - Descriptors - -
-
-

FIXME: Import this part from other doco

-
-
- - - -
- - Class and Resource Files - -
-
-

The class and resources files should be stored as in standard jars. The - root directory being the base via which code and resources are loaded. So - the - .class file for the Java class - com.biz.tasks.Mytask - would be stored in - /com/biz/tasks/Mytask.class -

-
-
- - - -
- - Dependencies - -
-
-

It is often the case that a library will need external resources. The - example given above described dependence on an external XML library. The - ant library thus needs a mechanism via which to declare dependencies on - external libraries.

-

Ant 2 uses the "Optional Package" mechanism. Prior to JDK1.3, an "Optional - Package" was known as an - Extension. The specification for this - mechanism is available in the JDK1.3 documentation in the directory - - $JDK_HOME/docs/guide/extensions/versioning.html. Alternatively - it is available online at - - - http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. -

-

This mechanism was adopted as it is an established standard. The standard - is also begining to be adopted by other specifications such as the - Servlet - 2.3 API. Thus we are likely to see an increase of jars using this mechanism - to specify dependencies. -

-

The "Optional Package" mechanism allows jars to specify dependencies on other - jars that implement a particular specification at particular version levels. For - example you could specify a dependency on the Trax 1.1 API by adding the following - to the manifest of your jar.

-
- - - - - - - - - - - - - - - - - 
-Extension-List: trax
-trax-Extension-Name: Java API for XML Parsing
-trax-Specification-Version: 1.1
-
-
-

In some cases you may also wish to specify a dependency on a specific vendors - implementation. For instance you may need to use xalan due to it implementing a - particular extension you need. In that case you manifest may contain;

-
- - - - - - - - - - - - - - - - - 
-Extension-List: trax
-trax-Extension-Name: Java API for XML Parsing
-trax-Specification-Version: 1.1
-trax-Implementation-Title: org.apache.xalan.xslt
-trax-Implementation-Version: 2.1.0
-trax-Implementation-Vendor: Apache Software Foundation
-
-
-

In many cases there will be no distinction between the specification and - the implementation of a library. For instance the Velocity project only has - one implementation and one specification. In which case it is sufficient to - just declare a dependency on the Velocity "Specification". A library that uses - both the Trax API and the Velocity project may look like;

-
- - - - - - - - - - - - - - - - - 
-Extension-List: trax velocity
-velocity-Extension-Name: org.apache.velocity
-velocity-Specification-Version: 1.0
-trax-Extension-Name: Java API for XML Parsing
-trax-Specification-Version: 1.1
-trax-Implementation-Title: org.apache.xalan.xslt
-trax-Implementation-Version: 2.1.0
-trax-Implementation-Vendor: Apache Software Foundation
-
-
-

To make other jars available to Ant libraries as "Optional Packages" - or Extensions then you need to add a few lines to the manifest of the - other jar. The minimal manifest is the following;

-
- - - - - - - - - - - - - - - - - 
-Extension-Name: org.realityforge.dve
-Specification-Vendor: Peter Donald
-Specification-Version: 1.0
-
-
-

It is important to note that looking for dependencies is recursive. For example, - if the ant library depends upon jar A and and A depends on B then both A and B will - need to be loaded by the container.

-
-
- - - -
- - Implementation Notes - -
-
-

So far there has been no mention of implementation strategies for - managing ClassLoaders and other details about where the "Optional Packages" - are stored. This section will outline such details but they could change - in the future. The above specification will still be accurate but the approach - to implementing specification will be different.

-

In the current architecture all of the "Optional Packages" are assumed to - be stored in the - $ANT_HOME/ext directory. The runtime will scan - this directory for jars and add all the "optional Packages" found into a - registry. This registry will be used by the library loading mechanism to locate - all the "Optional Packages". The user is able to specify an alternative directory - or add a new directory to search on the commandline. -

-

When the container attempts to load an ant library it will also try to load - any needed dependencies. First it will check the parent ClassLoaders to see if any - of them contain the required dependencies. If not then it will search the - "Optional Packages" registry. If the dependency is not found then a error will be - signaled. If the dependency is found in the "Optional Packages" registry then it is - loaded by the same ClassLoader that is used to load the Ant library.

-
-
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/task.html b/proposal/myrmidon/docs/task.html deleted file mode 100644 index c13b2f06e..000000000 --- a/proposal/myrmidon/docs/task.html +++ /dev/null @@ -1,242 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - My First Task - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - My First Task - -
-
-

In Ant 1 it was very easy to write your own task. In Ant 2 we plan -to make it even easier. To write a basic task simply follow the following -formula.

-
    -
  1. - Create a Java class that extends - org.apache.myrmidon.api.AbstractTask -
    2. -
  2. - For each attribute, write a setter method. The setter method - must be a public void method that takes a single argument. The name - of the method must begin with "set", followed by the attribute name, with - the first character of the name in uppercase, and the rest in lowercase. - The type of the attribute can be: -
      -
    • String
      • -
    • - Any primitive type - they are converted for you from their - String-representation in the buildfile -
      • -
    • - File - the string representation will be interpreted relative to - the project's basedir. -
      • -
    -
    3. -
  3. - For each nested element create a public void method that takes a single - argument. The name of the method must begin with "add", followed by the - attribute name, with the first character of the name in uppercase, and - the rest in lowercase. The type of the parameter is an object with a - no-arguement constructor. It is configured in exactly the same was a - task is configured (via setters and adders) and then added to the task. -
    4. -
  4. - Write a public void method named "execute" with no arguments that - throws a TaskException. This is the method called to do the - actual work of the task. -
    5. -
- - - -
- - A Basic Example - -
-
-

So a basic task that has one attribute named "message" and just prints -out this message is as simple as;

-
- - - - - - - - - - - - - - - - - 
-package org.realityforge.tasks;
-
-import org.apache.myrmidon.api.AbstractTask;
-import org.apache.myrmidon.api.TaskException;
-
-public class SystemOutPrinterTask
-    extends Task
-{
-    private String m_message;
-
-    // The setter for the "message" attribute
-    public void setMessage( final String message )
-    {
-        m_message = message;
-    }
-
-    // The method executing the task
-    public void execute()
-        throws TaskException
-    {
-        System.out.println( m_message );
-    }
-}
-
-
-

To use this task you could create a library but instead we will -just use <taskdef> to define the task. An example usage would be;

-
- - - - - - - - - - - - - - - - - 
-
-
-<?xml version="1.0"?>
-
-<project version="2.0">
-
-  <target name="main">
-    <taskdef name="printer"
-             classname="org.realityforge.tasks.SystemOutPrinterTask"
-             classpath="build/classes"/>
-
-    <printer message="Hello World!"/>
-  </target>
-</project>
-
-
-
-
-
-
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/todo.html b/proposal/myrmidon/docs/todo.html deleted file mode 100644 index d4e54da5d..000000000 --- a/proposal/myrmidon/docs/todo.html +++ /dev/null @@ -1,897 +0,0 @@ - - - - - - - - - - - - - - - - Apache Myrmidon - Get Involved - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Todo List - -
-
-

The broad goal is to grow Myrmidon from a prototype task engine into a fully - fledged build system, that can serve as the basis for Ant 2. The following - sections describe some of the many things which still need to be done to - achieve that goal. This list is currently under construction.

- - - -
- - Integrate XDocs proposal - -
-
-

Integrate with the XDocs proposal that generates XML documentation for - tasks. Rework that proposal so that it knows about the Myrmidon specific - patterns and features. Also rework it so that it can support reading - documentation and examples from side-by-side the task.

-
-
- - - -
- - TaskInfo - -
-
-

Consider allowing task writers to write their own TaskInfo objects - (or at least have them generated from XDoclet directives). This would - encompass both documentation and perhaps introspection of the types.

-
-
- - - -
- - XML Catalog to load XML Fragments - -
-
-

- 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. -

-
-
- - - -
- - Refactor Java Infrastructure into a Service - -
-
-

Much like Exec should be decoupled from Ant runtime, so should classes - to implement java task for the same benefits.

-
-
- - - -
- - Structural Dependency Utils - -
-
-

- 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. -

-

- 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 foo.c actually depends upon foo.h, bar.h - and baz.h. 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; -

-
- - - - - - - - - - - - - - - - - 
-public interface DependencyGenerator
-{
-  File[] generateDependencies( File file );
-}
-
-
-

- 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 foo.c may declare that - it is dependent upon foo.h, bar.h and baz.h, 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. -

-

- A possible API would be -

-
- - - - - - - - - - - - - - - - - 
-DependencyManager dm = ...;
-dm.setFileSet( myFileSet );
-dm.setDependencyCache( myDependencyCacheFile );
-File[] files = cm.getOutOfDate();
-
-
-
-
- - - -
- - Antlibs storing templates - -
-
-

After a templating system is formalized it would useful to define - a mechanism via which you can store templates in an antlib. These - templates could then be loaded and used by build files through a - "standard" mechanism. This may need to be merged with the XML catalog - system.

-
-
- - - -
- - Antlibs Storing General Resources - -
-
-

Add a system via which ant libs can store general resources for - consumption by build users. This could be used to store the XML fragments - for the XML catalog, the template fragments for templates, images for - documentation system and so forth.

-
-
- - - -
- - Coloring API - -
-
-

- 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 Foo.java, it may depend on the Bar.java - 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 Foo.java file was compiled with - debug="true" last run and this time needs to be compiled with - debug="false" then it is out of date and needs to be recompiled. We call this - "environmental" dependency information "coloring". -

-

- 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. -

-

- An API for such a bean has yet to be established but an example API would be. -

-
- - - - - - - - - - - - - - - - - 
-ColoringManager cm = ...;
-cm.addColor( "debug", "true" );
-cm.addColor( "optimize", "false" );
-cm.setFileSet( myFileSet );
-File[] files = cm.getOutOfDate();
-
-
-
-
- - - -
- - Create Task/Element/Attribute Naming guidelines - -
-
-

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.

-

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.

-
-
- - - -
- - Rethink Notification/Event scheme - -
-
-

We need to rethink the whole notificaiton scheme. Should tasks be able to - raise events? Probably as long as we have ContainerTasks. Should tasks - be able to query state of run? ie Can a task request "are we paused?" or "are we - stopped?" ? Probably as that way long running tasks are given the opportunity - to be gracefully halted by the end users (primarily aimed at IDE vendors here).

-
-
- - - -
- - XPath-like Locators for tasks - -
-
-

Most tasks are grouped into some sort of task container. The task containers - can be things like workspaces, projects, targets or other tasks. Each of these - containers usually has a name. Thus we could refer to tasks via a path such as - "/avalon/compile/javac" would refer to the task "javac" in the target "compile" - in the project "avalon". In the past it has been requested that a task get access - to this path programatically - other people have also asked for access to things - like the currently running target. We need to assess this and decide whether we - wish to support it.

-

Another point to think about is that we could use XPath-like string to designate - to other tasks to execute. ie antcall would refer to a path rather than a target name

-
-
- - - -
- - Embeddor HOWTO - -
-
-

Assigned To: Peter

-

Write a HOWTO describing how to embed Myrmidon into other - applications.

-
-
- - - -
- - Optional Dependencies - -
-
-

Assigned To: Peter

-

Extend Myrmidons library management facilities so that optional - dependencies may be declared for a library. ie The library will still - operate in absence of such libraries but can provide further features - if these libraries are present. Most likely this will be done via a - new manifest entry "Optional-Extension-List:" that behaves similar - to "Extension-List:" except that the extensions are optional.

-
-
- - - -
- - Facade task HOWTO - -
-
-

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 have a base - class that is meant to facilitate this sort of task and make it easy to develope. See - AbstractFacadeTask. However we need to write up a HOWTO so people can use it.

-
-
- - - -
- - Mail tasks - -
-
-

Convert the Ant 1.x Mail tasks to Myrmidon.

-
-
- - - -
- - Security Manager - -
-
-

Add the ability to run java programs that call System.exit() by adding a - security manager. Should look something like:

-
- - - - - - - - - - - - - - - - - 
-public class MyrmidonSecurityManager
-    extends SecurityManager
-{
-    public void checkExit( final int status )
-    {
-        throw new ExitException( status );
-    }
-
-    public void checkPermission( final Permission permission )
-    {
-    }
-}
-
-
-
-
- - - -
- - Self Hosting - -
-
-

Myrmidon must be able to build itself. Currently, it is built using - Ant 1.x. Ultimately, Myrmidon should be able to build itself from exactly the - same build file. To start with, however, there is no need for Myrmidon to be - able to do this. Myrmidon should also be able to be bootstrapped (that is, be - able to be built from scratch, without using Ant 1.x at all).

-
-
- - - -
- - Validation Pass - -
-
-

Consider calling validate() on task prior to execute(). This would allow - us to have a "make -k" mode that actually did basic validation and would also - encourage task writers to do validation properly.

-
-
- - - -
- - Paths - -
-
-

Consider allowing the user to configure the ant system by setting the - following path types.

-
    -
  • ant.type.path: path that is used to search for the type libraries
    • -
  • ant.ext.path: path that is used to search for "Optional Packages" - or extensions.
    • -
-

- The default search path will probably include a per-user path element, - a workspace path element and a system path elemtn that are searched in - that order. Some possible defaults; -

-
    -
  • Unix Per-user: ${user.home}/.ant/lib, ${user.home}/.ant/ext
    • -
  • Windows Per-user: ${user.home}/ant/lib, ${user.home}/ant/ext
    • -
  • MacOSX Per-user: ${user.home}/Library/Ant/lib, - ${user.home}/Library/Ant/ext
    • -
  • Unix System-wide: /opt/ant/lib, /opt/ant/ext
    • -
  • Unix System-wide: /usr/local/ant/lib, /usr/local/ant/ext
    • -
  • Windows System-wide: %SYS_DRIVE%/Program Files/ant/lib, - %SYS_DRIVE%/Program Files/ant/ext
    • -
  • MacOSX System-wide: /Library/Ant/lib, /Library/Ant/ant/ext
    • -
-
-
- - - -
- - Ant 1.x Compatibility - -
-
-

The Ant 1 Compatibility layer is still in early stages of development. -

-
    -
  • Get a version of <antcall> working.
    • -
  • - Provide hooks between Ant 1 references and Myrmidon properties. - May use converters for adapting Ant 2 objects (like Ant 2 - <path> or <fileset>) - as Ant 1 types. -
    • -
  • - Missing tests: -
      -
    • Make sure properties are shared between Ant 1 and Myrmidon tasks.
      • -
    -
    • -
  • Get GUMP runs going using Myrmidon.
    • -
  • Add protected accessors for get/set/list properties in - Ant 1 Project, to minimise the amount of code duplication in - Ant1CompatProject.
    • -
-
-
- - - -
- - Virtual File System - -
-
-

The VFS needs plenty of work:

-
    -
  • Move files/folders.
    • -
  • Recursive folders copy.
    • -
  • Search through a file hierarchy, using Ant-style wildcards.
    • -
  • Search through a file hierarchy, using a Selector interface.
    • -
  • The in-memory caching mechanism is pretty rudimentary at this stage. - It needs work to make it size capped. In addition, some mechanism needs - to be provided to release and refresh cached info. -
    • -
  • Convert files/folders into local files, for handing off - to external commands, or legacy tasks.
    • -
  • Refactor the replication mechanism out of ZipFileSystemProvder, - and make more general pluggable.
    • -
  • Capabilities discovery.
    • -
  • Attributes and attribute schema.
    • -
  • Handle file canonicalisation better (for cases like case-insensitive - file systems, symbolic links, name encoding, etc).
    • -
  • File system layering. That is, the ability for a file system to - sit on top of another file system, or a file from another file system - (e.g. Zip/Jar/Tar file systems, gzip/encoding file systems, virtual file - systems). -
    • -
-
-
- - - -
- - File Data-Types and Tasks - -
-
-

The file data-types, such as - <fileset> and - - <path>, are some of the most widely used parts of Ant 1.x. - Unfortunately, they aren't particularly extensible. -

-
    -
  • Redesign the file data-types, replacing them with an interface-based - API, plus a set of implementations. The API should use the VFS file - - FileObject, rather than - java.io.File. - This process has started, in the - antlib.vfile package. - -
    • -
  • File Selectors: - -
      -
    • Change - AbstractNameFileSelector to use Ant 1 style patterns - matches, rather than Globs patterns. -
      • -
    • Add 'defaultexcludes' to - DefaultFileSet. Also add a - file selector implementation that matches everything except the default - excludes. -
      • -
    • Add a name selector that loads patterns from a file.
      • -
    • Add more selector implementations: size and last-modified comparisons, - checksum comparison, byte-wise content comparison.
      • -
    -
    • -
  • File conditions: - -
      -
    • Add more condition implementations that perform checks on files. - One that searches a path for a file would be useful.
      • -
    -
    • -
  • File Name Mappers: - -
      -
    • Change FileNameMapper.mapFileName() to take vfs.FileName objects.
      • -
    • Move the current mapper implementations across to antlib.
      • -
    -
    • -
  • File Sets: - -
      -
    • Add a file set implementation that provides the union of several - nested file sets (that is, a file set that merges several file sets - together).
      • -
    • Add a file set implementation that filters files that are up-to-date - WRT some other file. Alternatively, this might be better done as a - file selector.
      • -
    -
    • -
  • Paths: - -
      -
    • Add path implementations that evaluate to the system classpath, - and the ant runtime classpath. Or, more generally, combine this with - - ClassLoaderManager to evaluate to the classpath of any - 'library' (e.g. system classpath, ant runtime, tools.jar, - an antlib, an installed extension, or the system classes of another JVM - for cross-compiling). -
      • -
    -
    • -
  • Port across the Ant 1 file filter proposal, once it is complete.
    • -
  • Copy task: - -
      -
    • Implement 'preservelastmodified', 'overwrite', and 'includeemptydirs'.
      • -
    • Support a file name mapper.
      • -
    • Support file filters.
      • -
    • Detect and handle destination file name collisions.
      • -
    -
    • -
  • Implement the - <move>, - <delete>, - - <touch> and - <mkdir> tasks on top - of the VFS and the new file data-types. Might be some scope for generalising - 'touch' and 'mkdir' into a single task. -
    • -
-
-
- - - -
- - Command-line and Configuration Files - -
-
-

One of the goals of Ant 2 is to allow the user to easily customise and - extend Ant. The command-line and local configuration files, are two places - where this would be done. Currently, Myrmidon some customisation from the - command-line, but does not support configuration files.

-
    - -
  • Load configuration from system (from $ANT_HOME) and user (from $HOME) - configuration files.
    • - -
  • Allow the following via config files: - -
      -
    • Add (or override) the - lib and - ext directories. -
      • -
    • Enable more than one listener, and configure the listeners from - the conents of the config file.
      • -
    • Import libraries, and set properties.
      • -
    • Execute tasks.
      • -
    • Install and configure runtime services.
      • -
    -
    • - -
-
-
- - - -
- - Scripting - -
-
-

Add the ability to extend Ant using languages other than - Java:

-
    -
  • Define a task using a scripting language such as Javascript.
    • -
  • Use Rhino's ability to implement Java interfaces, to - implement and define types, such as FileSelector, or - Condition.
    • -
  • Define a task using template.
    • -
  • Add some lightweight scripting tasks.
    • -
-
-
- - - -
- - Documentation - -
-
-

Everyone loves writing documentation, and so a goal for Ant 2 is to - generate a lot of reference documentation for tasks and other types directly - from the source. Unfortunately, there's still plenty of tutorial material - to write. In particular we need these:

-
    -
  • User documentation - describing things like the build file format, - how properties work, how to use references, how sub-builds work, how to customise - Myrmidon, and so on.
    • - -
  • Task writer documentation - describing things like an overview the task API, - how configuration works, task lifecycle, how to assemble an antlib, a catalog - of the runtime services, and so on.
    • - -
  • Myrmidon developer documentation - a broad outline of the architecture, - how to build, how to test, and so on. Also, this todo list needs plenty - of filling out.
    • - -
-
-
- - - -
- - Miscellaneous - -
-
-

A completely unordered list of items, big and small:

-
    -
  • Search through the code for 'TODO' items and fix them.
    • -
  • Allow service factories to be configured from the contents of the - - ant-services.xml descriptor. -
    • -
  • Add verbosity level to ProjectListener LogEvent
    • -
  • Fire ProjectListener events taskFinished(), targetFinished() and - projectFinished() events on build failure, adding indicator methods to - ProjectEvent.
    • -
  • Fire ProjectListener events projectStarted() and projectFinished() - events on start and finish of referenced projects, adding indicator methods - to ProjectEvent.
    • -
  • Detect duplicate type names.
    • -
  • Add fully qualified type names, based on antlib name and type shorthand name. - Allow these to be used in build files in addition to the shorthand names.
    • -
  • Move the - <http> and - <socket> - conditions to an antlib. Need to resolve how these will be passed a logger. -
    • -
  • Add an else block to the - <if> task. -
    • -
  • Move - crimson.jar to - bin/lib in the distribution, - and make available to other jars via the extension mechanism. -
    • -
  • Change DefaultPropertyResolver to ignore '$${'.
    • -
  • Add a --type command-line option, to allow - the project builder to be manually selected. -
    • -
  • Change ProjectBuilder - and Embeddor to throw something more - specialised than Exception. -
    • -
  • Change DefaultClassLoaderManager to handle - directories as part of a library classpath. -
    • -
  • <condition> should set the property - value to false when the condition is false.
    • -
  • Split the <uptodate> condition into - a condition that checks against a single target file, - and one which checks using a destdir/mapper.
    • -
  • Add condition implementations to: check JVM version, - check Ant version, check whether a particular antlib or extension is - available, match a string against a regular expression.
    • -
  • Add a task to unset a property.
    • -
  • Change the various def and import task to allow a classpath - to be provided.
    • -
  • Unit tests.
    • -
-
-
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/user.html b/proposal/myrmidon/docs/user.html deleted file mode 100644 index 588b42104..000000000 --- a/proposal/myrmidon/docs/user.html +++ /dev/null @@ -1,311 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - User Guide - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Building Myrmidon - -
-
-

-First, you will need to fetch the Myrmidon source from CVS. The source -can be found in the proposal/myrmidon directory of the -Ant source tree. You should check out the jakarta-ant CVS -module, as described -here. -

-

-To build Myrmidon, use the build.xml build script. You will need -to use Ant 1.4.1 or later. The default target builds the Myrmidon distribution -into the dist directory. The distribution is a ready-to-run -installation of Myrmidon. -

-

There are a number features that are not built unless the appropriate optional Jar -files are found in the lib directory:

- - - - - - - - - - - - - - - - -
- - Feature - - - - Jar File - - - - Download From - -
- - SMB VFS support (Samba, Windows shares) - - - - jcifs.jar - - - - jcifs.samba.org. -

Note: there are problems using the 0.6.1 release. Try 0.6.0 instead.

- -
- - FTP VFS support - - - - netcomponents.jar - - - - www.savarese.org - -
-
-
- - - -
- - Running Myrmidon - -
-
-

-To run Myrmidon, use one of the following methods: -

- - - -
- - Launcher Script - -
-
-

-On Windows and Unix platforms, you can use the ant script -in the distribution's bin directory. The following environment -variables can be used, but are not required (except on Windows 9x - see below). -

-

- -

- - - - - - - - - - - - - - - - - -
- - Variable - - - - Description - -
- - JAVA_HOME - - - - The directory that the JDK is installed in. - -
- - JAVACMD - - - - The command to use to start the JVM. Defaults to java. - -
- - ANT_HOME - - - - - The directory containing the Myrmidon distribution. This must be - set when running on Windows 95, 98 or Me. - - -
-
-
- - - -
- - Executable Jar File - -
-
-

-The Myrmidon distribution includes an executable Jar file, which can be used -to run Myrmidon. Use the following command: -

- 
-prompt> java -jar ant-home/bin/myrmidon-launcher.jar options
-
-
-
-

When started, Myrmidon looks for a project file called build.ant -in the current directory. A different project file can be specified using the --f command-line option. Myrmidon executes the targets that are -listed on the command-line, or the default target if none is given. For -example, the following command executes targets clean and -build from project file my-project.xml:

- 
-prompt> ant -f my-project.xml clean build
-
-

-Run Myrmidon with the -h command-line option for a list of -the command-line options that are available. -

-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/docs/vfs.html b/proposal/myrmidon/docs/vfs.html deleted file mode 100644 index 4ca60720b..000000000 --- a/proposal/myrmidon/docs/vfs.html +++ /dev/null @@ -1,432 +0,0 @@ - - - - - - - - - - - - - - Apache Myrmidon - VFS User Guide - - - - - - - - - - -
- -
Apache Myrmidon
- - - - - - - - - - - - -
-
-
-

Myrmidon

- -

User Guide

- -

Extending Ant

- -

Container Design

-
    -
- 		- - - -
- - Handling Files - -
-
-

Myrmidon includes a Virtual File System (VFS), which allows files from - different sources to be treated identically. The VFS currently supports - the following file types:

- - - - - - - - - - - - - - - - - - - - - - - - - - -
- - File System - - - - Description - - - - URL Format - -
- - Local Files - - - - Files on the local file system. - - - - Three different formats are currently supported for local file names: -
    -
  • file:// absolute-file-name
    • -
  • Absolute file names
    • -
  • Relative file names. These are resolved relative to the - project's base directory. -
    • -
- - -
- - Zip Files - - - - The contents of Zip files (and Jar, War, and Ear files). - Currently, the VFS supports read-only access to Zip file contents. - - - - zip: zip-file-uri [!absolute-path] - -
- - FTP - - - - Files on an FTP server. - - - - ftp:// [[password:] username@] hostname [:port] [absolute-path] - -
- - SMB - - - - Files on a CFIS server, such as Samba or Windows shares. - - - - smb:// [[password:] username@] hostname [:port] [absolute-path] - -
-

Both forward or backward slashes can be used to separate the elements of - a URL.

-

Here are some example URLs:

-
    -
  • build/classes
    • -
  • c:\program files\ant\bin
    • -
  • file://C:/program files/ant
    • -
  • zip:build/lib/ant.jar!/org/apache/tools
    • -
  • ftp://adam@somehost/pub/downloads
    • -
  • smb://password:adam@somehost/home/adam
    • -
-

Currently, there are only a handful of VFS aware tasks. This will grow - as more tasks are ported to the new API, and data types.

- - - -
- - File Sets - -
-
-

A file set in Myrmidon is more general than Ant 1's concept of a file set. - Firstly, there is more than one type of file set. Secondly, they are VFS enabled. - File sets are automatically converted to a path, and so - can be used anywhere that a path can.

-

<v-fileset>

-

This is the equivalent of Ant 1's <fileset> (The name - is temporary, it will be changed to <fileset> once more - porting work as been completed).

-

Rather than use a set of include and exclude patterns to choose the files - that make up the file set, <v-fileset> takes zero or more - file selectors. File selectors can be used to - select files based on any attribute of the file, rather than just the name. - You can use <name> selectors to achieve the same result - as using includes or excludes.

-

A <v-fileset> element takes the following attributes:

- - - - - - - - - - - -
- - Attribute - - - - Description - - - - Default Value - -
- - dir - - - - The base directory for the file set. This can be any URL that the - VFS supports. - - - - Required - -
-

A <v-fileset> element takes any number of nested - file selector elements. To be included in the - file set, a file must be selected by all the file selectors. That is, the - file selectors are implicitly AND-ed together. If no file selector is provided, - all the files and directories are included in the set.

-

An example:

-
- - - - - - - - - - - - - - - - - 
-
-<v-fileset dir="src">
-    <name pattern="org/apache/tools/ant/**"/>
-    <is-file/>
-</v-fileset>
-
-
-

<flat-fileset>

-

This file set takes a set of nested file sets and paths, and flattens them - into a single directory. It can be used as a way of converting a path into a - file set. It can also be used as a replacement for the flatten - attribute for the copy and move tasks.

-

A <flat-fileset> element takes no attributes, and a set - of nested paths or file sets.

-

An example:

-
- - - - - - - - - - - - - - - - - 
-
-<v-copy todir="dist/lib">
-  <flat-fileset>
-    <v-fileset dir="build/lib">
-      <basename pattern="*.jar"/>
-    <v-fileset>
-    <v-path path="${classpath}"/>
-  </flat-fileset>
-</v-copy>
-
-
-

<mapped-fileset>

-

A fileset that applies a file name mapper - to a nested fileset. -

-
-
- - - -
- - Paths - -
-
-

Paths are an ordered list of files.

-

<v-path>

-

This is the equivalent of Ant 1's <path>.

-

<filtered-path>

-

A path that applies file selectors to a set of nested file sets and paths.

-
-
- - - -
- - File Selectors - -
-
-

File selectors are used to select files from file sets and paths.

-

<and>

-

Combines zero or more file selectors, using AND. An empty <and> - selector accepts all files.

-

<basename>

-

Selects files whose base name matches an Ant 1 style pattern, or a regular - expression.

-

<condition>

-

Takes a set of conditions. If - the conditions evaluate to true, then select every file. Otherwise, - select no files.

-

<exists>

-

Selects files that exist.

-

<is-empty-folder>

-

Selects empty folders, that is, folders that have no children.

-

<is-folder>

-

Selects folders, does not select regular files.

-

<is-file>

-

Selects regular files, does not select folders.

-

<name>

-

Selects files whose path in a file set matches an Ant 1 style pattern, or - a regular expression.

-

<not>

-

Selects files that are not selected by a nested file selector.

-

<or>

-

Combines zero or more file selectors, using OR. An empty <or> - selector accepts all files.

-

<url>

-

Selects files whose URL matches an Ant 1 style pattern, or a regular expression.

-
-
-
-
-
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - - - - - - diff --git a/proposal/myrmidon/src/xdocs/ant1compat.xml b/proposal/myrmidon/src/xdocs/ant1compat.xml deleted file mode 100644 index 4fca81496..000000000 --- a/proposal/myrmidon/src/xdocs/ant1compat.xml +++ /dev/null @@ -1,112 +0,0 @@ - - - - Darrell DeBoer - Ant 1 Compatibitlity Layer - - - - -
-

- The Myrmidon-Ant1 Compatibility layer works by reusing most of the Ant 1 code, - with tasks and datatypes - being prefixed with "ant1." in build files. Almost all of the main Ant 1 tree - is included in the compatibility layer antlib. To insulate from changes in - the Ant 1 tree, Ant 1 class files are extracted from a jar, rather than - being compiled from scratch. -

-

- Here's how it works: The first time an Ant 1 task is encountered, an Ant 1 - project is created, and stored in the TaskContext under the name "ant1.project". - The Ant 1 versions of Task and Project have been extended, overriding core behaviour, - with Myrmidon-specific behaviour. -

-

- The updated version of Task implements Configurable, receiving it's - complete Task Model, and actually setting/adding/creating attributes - with the help of the IntrospectionHelper. This process is designed to - mimic the Ant 1 configuration policy, although not all of the - subtle variations of configuration present in Ant 1 are handled. -

-

- The updated version of Project will provide hooks into the Myrmidon TaskContext, - such as:

-
    -
  • logging (done)
    • -
  • properties (done)
    • -
  • references (not yet done)
    • -
  • Task defined by <taskdef> (done)
    • -
- -

- So at present, properties declared in Ant 2 tasks are available to all Ant 1 tasks, - and vice-versa. However, while a <ant1.path> reference works fine - in other <ant1.XXX> - tasks, it's not visible to Ant 2 tasks in the same build, and vice-versa. -

- -

- The <taskdef> task works ok, registering the task with the TypeManager using the - "ant1." prefix. Only a couple of DataTypes (Path and Patternset) are working - as top-level types, but this should be just a matter of adding references to - the Ant 1 version of TypeInstanceTask in the descriptor. -

- -

- The TransformingProjectBuilder (which is now the default builder for files - of type ".xml", applies a transformation stylesheet to the file, prefixing select - tasks (all at present) with "ant.". If a version attribute is encountered, the - file is not transformed -

-
- -
- -

- If you have a Myrmidon build file (eg with version="2.0" - on the project element, you can use Ant 1 tasks and datatypes by using - the "ant1." suffix on the regular element name. - Virtually all tasks and datatypes from Ant 1.4.1 are available - in this way. -

-

- When declaring a new task using the <ant1.taskdef> - task, don't prepend "ant1." to the taskname. This will be - done automatically by the taskdef task. However, you will need - to use the "ant1." prefix in all uses of that task. -

- - - -

- Myrmidon will automatically handle Ant 1 build files using the - Ant 1 Compatibility layer. So, using an Ant 1 build - file with Myrmidon should be as simple as:

- 
[myrmidon-command] -f ant1-build-file.xml
-

- This works as follows: When Myrmidon encounters a ".xml" build file which does not have a - version attribute on the top-level project - element, it assumes that it is an Ant 1 build file. So all tasks are - interpreted as though they are prefixed with the "ant." name prefix. -

- - Myrmidon will automatically attempt to upgrade any ".xml" build file that - -
- -
-

Before building the Ant 1 Compatibility layer, you need to build - Myrmidon, running the dist-lite target of the main build. - See the build instructions - for more details.

- -

To build the compatibility layer, simply execute:

- 
ant -f ant1compat.xml
-

from within the root directory of the Myrmidon source tree.

- -
- - - - diff --git a/proposal/myrmidon/src/xdocs/buildfile.xml b/proposal/myrmidon/src/xdocs/buildfile.xml deleted file mode 100644 index 5aebfd7fc..000000000 --- a/proposal/myrmidon/src/xdocs/buildfile.xml +++ /dev/null @@ -1,295 +0,0 @@ - - - -Adam Murdoch -User Guide - - - - -
- -

-A project file is an XML file that describes which tasks to execute, and in -which order to execute them in. A project can be broken up into several steps, -or targets. A target is simply a list of the tasks that need to be -executed to perform the step. A target may also include some dependency -information. Myrmidon makes sure that targets are executed in the correct order, -so that a target is executed before the targets that depend on it.

- -

The project file format is very similar to the format used in Ant 1. The -root element of a project file must be a <project> element. -It can take the following attributes: -

- - - - - - - - - - - - - - - - - - - - - - - -
AttributeDescriptionDefault Value
nameThe project name.The name of the project file, with the extension removed.
basedirThe base directory for the project. The base directory is used - to resolve all relative file names used in the project file. - The directory containing the project file.
defaultThe name of the default target.main
versionThe project file format version that the project is written for.None, must be 2.0
- -

-A <project> element can contain the following elements, -in the order given below: -

- - - - - -

Project references allow the project to import, or reference, other projects. -A <projectref> element takes the following attributes:

- - - - - - - - - - - - - -
AttributeDescriptionDefault Value
nameThe name to use to identify the referenced project.Required
locationThe path to the project file to reference.Required
- -

-The targets of a referenced project can be used in the depends list -of a target in the referencing project, using the syntax -project-name->target-name. Here is a simple example:

- - - - - - - - .. do some stuff .. - - -]]> - - - - - -

Library imports allow the project to import the tasks and data-types from an -antlib. An <import> element takes the following attributes:

- - - - - - - - - - - - - - - - - - -
AttributeDescriptionDefault Value
libraryThe name of the library to import. The ext directory - of the Myrmidon distribution is searched for a library file with - the given name, and an atl extension.Required
typeThe type of definition to import. Values include task, - and data-type.None
nameThe name of the type to import.None
- -

-If the type and name attributes are not provided, -the entire contents of the antlib are imported. -

- -

The following example import the <my-task> task from -the my-tasks antlib.

- - - - - - - - - -]]> - - - - - -

Initialisation tasks are run before any of the project's targets are run, and -are used to initialise the project. Any task can be used as an initialization -task, including <property> and data-type instances. An example:

- - - - - - - - Set classpath to ${classpath} - - - .. do some stuff .. - - - -]]> - - - - - -

Targets have a similar format to targets in Ant 1.x, though some of the -behaviour is different. A <target> element takes the -following attributes:

- - - - - - - - - - - - - -
AttributeDescriptionDefault Value
nameThe name of the target.Required
dependsA comma-separated list of targets that this target depends on. - This list can contain targets from referenced projects.None
- - - -
- -
- -

- Listed below are some of the current set of tasks. You can find example - usages of these tasks in the sample project file src/make/sample.ant. -

- -

<condition>

- -

Sets a property if a particular condition is true. See - Conditions for a list of available conditions.

- -

<fail>

-

Causes the build to fail.

- -

<if>

-

Conditionally executes a set of tasks.

- -

<load-properties>

-

Loads a set of properties from a file.

- -

<log>

-

Writes a log message.

- -

<property>

-

Sets a property.

- -

<try-catch>

-

Runs a set of tasks, with a provided error and clean-up handler.

- -

<converter-def>

-

Register a type converter. These are used when configuring a task - or data-type from attributes.

- -

<type-def>

-

Register a task or data-type.

- -

<import>

-

Register the contents of an antlib.

- -
- -
- -

The following conditions are available

- -

<and>

-

Evaluates a set of nested conditions, and AND them together. Evaluation is - lazy. An empty <and> condition evaluates to true.

- -

<available>

-

Tests if a particular class or resource is available.

- -

<file-test>

-

Tests a file against a set of file selectors.

- -

<is-set>

-

Tests whether a proeprty is set, and not set to 'false'.

- -

<or>

-

Evaluates a set of nested conditions, and OR them together. Evaluation is - lazy. An empty <or> evaluates to true.

- -

<os>

-

Tests which operating system the build is running on.

- -

<not>

-

Negates a nested condition.

- -
- -
- -

The following file name mappers are available:

- -

<chain>

- -

Applies a set of nested file name mappers to file names.

- -

<flatten>

- -

Maps all file names to a single directory.

- -

<prefix>

- -

Adds a prefix to the front of each file name.

- -

<map-extension>

- -

Changes the extension of file names.

- -
- - - diff --git a/proposal/myrmidon/src/xdocs/classloader.xml b/proposal/myrmidon/src/xdocs/classloader.xml deleted file mode 100644 index 0a08ff87c..000000000 --- a/proposal/myrmidon/src/xdocs/classloader.xml +++ /dev/null @@ -1,136 +0,0 @@ - - - - - On ClassLoaders in Ant 2 - Peter Donald - - - - -
- -

In many ways Ant 2 needs to follow rules similar to a number of - different application servers with respect to ClassLoader management. - Ant 2 will create a number of different ClassLoaders that have access - to different sets of resources (and thus Classes). The main reason - for this arrangment is to partition different sections of the - application such as the Container, the Task API, task/type libraries - and support libraries.

- -

The recomended structure for ClassLoader relationships is a hierarchy. - When a ClassLoader is asked for a resource (or a class) it first delegates - to it's parent to ask for the resource. If the resource is not present in - its parent ClassLoader then the ClassLoader attempts to locate the resource - in it's own store. In practice this means that all the classes (and static - variables defined by said classes) in a parent ClassLoader are shared with - the child ClassLoaders.

- -

Using kooky ascii art, the specific ClassLoader structure for Ant 2 is as - follows:

- - - Bootstrap - | - System - | - Common - / \ - Container Shared - / \ - Antlib1 Antlib2 ... - - -
    -
  • - The - Bootstrap ClassLoader contains the classes and resources - provided by the Java runtime. - -
    • -
  • - The - System ClassLoader contains the classes that were made accessible - via the CLASSPATH environment variable. If the standard ant script was used then this - should only contain the classes that are used to bootstrap the ant runtime. ie - - $ANT_HOME/bin/ant-launcher.jar -
    • -
  • - The - Common ClassLoader contains the classes and resources - that are made visible to both the Container and to all the ant type libraries. This - contains all the classes that the Container uses to communicate with tasks and other - supporting infrastructure. In particular it contains the following APIs; - -
      -
    • - Task API - Contains the classes that are part of the API used - to define tasks. - -
      • -
    • - ProjectListener API - Contains the classes necessary to define new - ProjectListeners. - -
      • -
    • - Aspect API - Contains the classes that are used to define Aspects - of the container. - -
      • -
    • - Container API - Contains the interfaces that are required to communicate - with the objects deep within the container. - NOTE: These interfaces - are not to be used by user tasks but are made available so that certain tasks (such - as <antcall/>) can be implemented. However they are subject to change without - notice between between different Ant 2 versions. - -
      • -
    -

    - These classes are loaded from all the jars present in the - $ANT_HOME/lib - directory. - -

    -
    • -
  • - The - Container ClassLoader contains all the classes and resources - that are part of the actual implementation of the Container. These classes are not - directly accessible to any Ant library or task. Some of the classes are indirectly - accessible to tasks and other elements defined in the ant libraries as they implement - interfaces defined in the - Common ClassLoader. The classes that are - stored in jars in the - $ANT_HOME/bin/lib/ directory. - -
    • -
  • - The - Shared ClassLoader contains all the classes and resources - that are shared across all of the ant libraries (unless they are als needed by the - container in which case they should be placed int the - Container - ClassLoader). This ClassLoader is populated by all the jars that are contained in - the - $ANT_HOME/shared/ directory. - -
    • -
  • - The - AntLib ClassLoaders each contain the classes and resources - that required by that particular library. Note that in some cases a single Ant - Library will manifest as a single ClassLoader containing a single jar. However - in some cases it is possible for one Ant Library to have multiple jars in its - ClassLoader or even have multiple ClassLoaders. See XXXX for further details. - -
    • -
- -
- - - diff --git a/proposal/myrmidon/src/xdocs/configuring.xml b/proposal/myrmidon/src/xdocs/configuring.xml deleted file mode 100644 index fe98cf7ab..000000000 --- a/proposal/myrmidon/src/xdocs/configuring.xml +++ /dev/null @@ -1,205 +0,0 @@ - - - - - On Task Configuring in Ant 2 - Peter Donald - - - - -
-

This section will describe in detail the mechanism via which tasks are - configured. Configuration is the name given to the stage in tasks - lifecycle via which the XML representation is mapped onto the task - object.

-
- -
- -

When mapping the XML representation on to the task object you - need to be able map the names as they appear in the XML to the - names as they appear in the Java code. The process is for generating - a java name from the xml name is as follows.

-
    -
  1. Capitalize the first character of name.
    2. -
  2. Find any '-' characters in XML name and remove character and - capitalize the following letter. (And there must be a following - letter)
    3. -
-

Some example mappings;

- -my-name ===> MyName -aString ===> AString -Basedir ===> Basedir -baseDir ===> BaseDir -url ===> Url -

Note that the above transformation is lossy and as such the - following XML names all map to the same Java name. The ant1.x mapping - is similarly lossy and in practice this has not been an issue.

- -base-dir ===> BaseDir -Base-dir ===> BaseDir -baseDir ===> BaseDir -BaseDir ===> BaseDir -

NOTE: We should really resolve this and either disallow '-' characters - or disallow uppercase or something. (PD)

-
- -
-

The first stage of mapping the XML representation to the task - is resolving all text data. The text data that needs to be resolved - include the values of attributes and the content.

-

Resolution consists of expanding any property references in the text - data. Property references are identified as starting with the token - "${" and finishing with another "}" token. The text - in between is the name of a property. The value of the property replaces - the sequence of text starting with the "${" token and finishing - with the "}" token.

-

Note that the value of the property may not be a string. If the text data - contains text (or other property references) to either side of the property - reference then it must be converted to a - String.

-
- -
-

Currently the representation of object are stored in a hierarchial - tree of org.apache.myrmidon.api.metadata.ModelElement - objects. Each ModelElement has a number of attributes and can have - either content or sub-elements.

-

In most cases it is the responsibility of the runtime to map - the ModelElement onto an object. However in some cases it may be useful - for the object to get access to it's own model and for it to explicitly - manage it's own configuration. In this case the object should implement - the org.apache.myrmidon.api.metadata.Modeller interface - which will provide the mechanism for the object to receive its own - representation and configure itself.

-

Note that the Modeller mechanism should be avoided if possible - as it adds considerable complexity to the implementing object.

-
- -
-

To map an XML attribute on to a Java object, the name of the - attribute is mapped to a java name and prefixed with the string - "set". The resulting string is then used to look up a - method with a single parameter.

-

For example, for the attribute "world" would result - in a lookup of a method named "setWorld" with a single - parameter.

-

If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity. Theres is an exception - to this rule that allows 2 methods to be matched if one of the - methods takes a java.lang.String parameter. The method - that has the java.lang.String parameter is ignored and - the other method would be chosen. This exception is allowed as it is - common practice for a task to evolve from String parameters to more - strongly typed parameters.

-

The resolved text data of the attribute must be - converted to the type of the matched - methods parameter. For example, if the "setWorld" method - took a parameter of type java.io.File then the resolved - text data must be converted into a java.io.File. The - conversion is done by the Converter architecture that is more fully - described in the Converter HOWTO.

-

After the value is converted to the correct type the method is - invoked with the converted value.

-
- -
-

The XML representation of object can have either have nested - elements or nested text (content) but not both. To add the content - to an object a method named "content" with one parameter is looked - up. The resolved text data for content is then - converted to the type of the parameter - and passed in via the method.

-
- -
-

Mapping an ModelElement onto a java object is a series of steps. - If the ModelElement name ends with the string "-ref" then - it is treated as a reference element - see the Referrenced - Elements section. Otherwise, the element is first attempted to - be mapped as a Named Element and if no match is found via - that method it tries to treat the element as a Typed Element.

- -

To map a named ModelElement on to a Java object, the name of - the element is mapped to a java name and prefixed with the string - "add". The resulting string is then used to look up a - method with a single parameter.

- -

For example, for the attribute "geometry" would result - in a lookup of a method named "addGeometry" with a single - parameter. If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity. If no methods were found that - match name then skip down to configuring "typed" elements.

- -

The type of the methods single parameter is then examined to determine - what happens next. There are two valid situations, if neither of these are - satisfied, then an exception is thrown.

-
    -
  • The parameters type is org.apache.myrmidon.api.metadata.ModelElement
    • -
  • The parameters type is a concrete class
    • -
-

1. If the parameter has a type of org.apache.myrmidon.api.metadata.ModelElement - then the un-modified model representation of element is passed to object by invoking - the adder method.

-

2. If the parameters type is concrete then an instance of the parameter is - instantiated using the default constructor. This created object is then configured - in the same manner as task using the elements representation as the model. After - the object is configured it is passed into object by invoking the adder method.

- - -

A referenced element is one that has a name ending in - "-ref" and has a single attribute "name" - and no content or child elements.

- -

The value of the "name" attribute is the name of a property. - The value of this property is retrieved from the TaskContext.

- -

Like with Named Elements the name of the element (minus - the "-ref" part) is mapped to a java name and prefixed with the string - "add". The resulting string is then used to look up a - method with a single parameter. If multiple methods were matched during the lookup then an - exception is thrown indicating ambiguity.

- -

The value retrieved from the TaskContext is then converted to the type - of the methods parameter and the add method is invoked with the converted value.

- -

An example usage is the following;

- - - - -]]> - - -

"Typed" elements can also be added to an object. A typed element - is one in which the name of the element actually refers to a type rather than the - name of the adder to call.

-

For example, you may wish to allow a task to add arbitrary instances of the - Condition role to a task. So instead of adding methods such as - addAnd(AndCondition), addOr(OrCondition) and - addXor(XorCondition) you can instead add a single method - add(Condition). This vastly simplifies the amount of work required - to write tasks that take conditions. More importantly it allows end-users to - extend the number of elements selected by task. For instance if the user wanted - a "nand" condition they could write the Nand type use it in their build - file. For a discussion on roles and types see the Types - HOWTO.

-

To use a Typed adder there must be a single method named "add" that - has a single parameter. The parameter MUST be an abstract interface and - must be registered as a role. The name of the element is then used to lookup the - a type in the TypeManager with a role matching the interface name.

- -

For example if an element named "nand" was added to an object that had - an adder with the signature void add( Condition condition ) then - the type named "nand" in the role "Condition" would be looked up. - An instance of the type would then be created using the default constructor and the - created object would be configured and then adder to object using adder.

- - -
- - diff --git a/proposal/myrmidon/src/xdocs/differences.xml b/proposal/myrmidon/src/xdocs/differences.xml deleted file mode 100644 index 333677e23..000000000 --- a/proposal/myrmidon/src/xdocs/differences.xml +++ /dev/null @@ -1,49 +0,0 @@ - - - Adam Murdoch - Differences to Ant 1 - - - -
- -

Some of the differences between Ant 1.x and Myrmidon:

-
    -
  • - Groups of tasks can be assembled into self-describing - antlib task libraries. This makes it very easy to - distribute and install tasks and data-types. -
    • -
  • A project can import other projects, and reference their targets.
    • -
  • Properties and data type references now share the same namespace.
    • -
  • - Changes to task and data-type API: -
      -
    • An interface based API, through which a task interacts with the - task engine, and the services it provides.
      • -
    • A well-defined object lifecycle.
      • -
    • Polymorphic types are supported when objects are configured.
      • -
    • Reference handling is handled automatically when objects are configured.
      • -
    • Aspects can be used to decorate tasks, to add facilities like logging, - error handling, or user preferences.
      • -
    -
    • -
  • A set of well-defined services and APIs have been introduced, to allow - tasks to do their work without depending on other tasks: -
      -
    • Execute external commands.
      • -
    • Execute other tasks.
      • -
    • Manage ClassLoaders and Class-paths.
      • -
    • Virtual file system (in progress).
      • -
    • Execute Java applications (in progress).
      • -
    • ...
      • -
    -
    • -
-

There are plenty more features planned. You can read about them - here. -

-
- - - diff --git a/proposal/myrmidon/src/xdocs/getinvolved.xml b/proposal/myrmidon/src/xdocs/getinvolved.xml deleted file mode 100644 index 39b0dbf69..000000000 --- a/proposal/myrmidon/src/xdocs/getinvolved.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - Adam Murdoch - Get Involved - - - -
- -

There are plenty of things you can do to help out with Myrmidon. The - Todo list describes items which still need to - be done. Of course, since this is an open-source project, there's - plenty of scope for experimentation, and you can pretty much make up - your own items to work on.

- -

Some things that are worth reading if you do want to get involved:

- - -

There is no Ant 2 or Myrmidon mailing list yet, so direct any questions - or comments you have to the ant-dev mailing list.

- -
- - - diff --git a/proposal/myrmidon/src/xdocs/index.xml b/proposal/myrmidon/src/xdocs/index.xml deleted file mode 100644 index a2631bd23..000000000 --- a/proposal/myrmidon/src/xdocs/index.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - - Peter Donald - Myrmidon - - - -
- -

Ant is a cross-platform build tool that features ease of - use and extensibility as it's primary goal.

- -

Why another build tool when there is already make, gnumake, - nmake, jam, and others? Make-like tools are inherently shell-based; - they execute native commands and shell scripts to perform the work - associated with the build process. So to extend the the tool by - writing a program or script executable by the OS you are on. This - makes it difficult to achieve portability between platforms.

- -

Ant is a different beast. Instead of using OS-specific commands - to extend the build process, you leverage the cross-platform features - of Java to write "tasks". This makes it much easier to achieve - a portal build process between platforms. Ant also differs in that it uses - XML to describe the build process.

- -
- -
- -

Myrmidon is a proposal for Ant 2. Ant 2 is the next evolution of the - Ant build tool aimed at removing many of the limitations of the Ant 1.x - product. In particular it aims to;

- -
    -
  • Remove ambiguities and points of confusion for build file - writers.
    • -
  • Ease deployment and management of 3rd party tasks and - dependencies.
    • -
  • Simplify development of tasks by task-writers.
    • -
  • Enable ad-hoc "tasks" to be written inside build file, - probably using well known scripting languages such as python and - javascript. (Possible in Ant 1.x but prohibitively difficult).
    • -
  • Integrate templating technologies such as XSLT, velocity etc - to enable development of reusable build file elements.
    • -
- -

You can read more about the goals of Ant 2 - here. -

- -

Myrmidon was specifically designed as both a tool and as - an API library that can be reused in other products. It contains the - basic building blocks for assembling any sort of task-based tool. Ant 2 - is an example of such a tool, which could be assembled using the Myrmidon - task container, and a library of build related tasks. In the future expect - to see Testing frameworks, Job Schedulers (ie Cron managers), shells - and install tools based on the Myrmidon base.

- -
- -
-

- The name Myrmidon is a derivation of a mythological name for some ants that were turned - into soldiers by the god Zeus. It came to mean "a subordinate who executes orders - unquestioningly" which seemed suitable for a task execution/build tool. A more complete - description stolen from - - http://bondi-blue.parlez.com/previous_words/myrmidon.txt. -

- - - The appellation Myrmidon was derived from the Greek word "myrmex", - meaning ant. According to Greek mythology, the Myrmidons were - transformed into humans by the god Zeus as an act of kindness to his - son Aeacus. King Aeacus, captivated by a colony of ants, prayed - that he should receive an increase in population equal to the - number of ants before him. When he awoke the next day, the ants - were his human subjects. Thereafter, they were known as the - Myrmidons. See "The Iliad" for Homers' account of the Myrmidons - during the Trojan War. - -
- - diff --git a/proposal/myrmidon/src/xdocs/librarys.xml b/proposal/myrmidon/src/xdocs/librarys.xml deleted file mode 100644 index 795c73eaf..000000000 --- a/proposal/myrmidon/src/xdocs/librarys.xml +++ /dev/null @@ -1,187 +0,0 @@ - - - - - On Libraries in Ant 2 - Peter Donald - - - - -
- -

Long ago there was identified the need for libraries that contain - tasks and other elements present in the build file. This document - attempts to describe the mechanism via which these libraries will be - defined and used in Ant 2. The libraries (also referred to as - deployments) will be termed antlibs.

- -

Ant libraries can be packaged and signed into a ANt Type Library - format (.atl) using the standard Java Archive tools. (For details on - the .jar file format see the - - - Jar Specification. -

- -

When packaged into such a form the META-INF/ directory contains - ant specific descriptors in addition to the standard Jar manifest - and other descriptor files. The archive will also contain the - - .class files for all the tasks and other types the - library defines. It may also contain additional resources that can - be referenced in the build file (an example being DTDs). -

- -

The library may also need access to other libraries or resources - to perform its job. For instance, if the task loaded an XML document - and then processed said document using the - Trax API then - the Ant library needs to have access to the - Trax API and an - implementation of the API. The Antlib mechanism thus uses the standard - "Optional Package" Specification to declare dependencies on other - libraries. -

- -

The libraries will usually be installed in standard locations that - make it possible for the Ant container to automatically locate and scan - the libraries. It will also be possible for the users to specify - additional search locations or even the specific location of ant - libraries.

- -

The following sections will describe each of these different facets - in greater detail.

- - - -

FIXME: Import this part from other doco

- - - - - -

The class and resources files should be stored as in standard jars. The - root directory being the base via which code and resources are loaded. So - the - .class file for the Java class - com.biz.tasks.Mytask - would be stored in - /com/biz/tasks/Mytask.class -

- - - - - -

It is often the case that a library will need external resources. The - example given above described dependence on an external XML library. The - ant library thus needs a mechanism via which to declare dependencies on - external libraries.

- -

Ant 2 uses the "Optional Package" mechanism. Prior to JDK1.3, an "Optional - Package" was known as an - Extension. The specification for this - mechanism is available in the JDK1.3 documentation in the directory - - $JDK_HOME/docs/guide/extensions/versioning.html. Alternatively - it is available online at - - - http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html. -

- -

This mechanism was adopted as it is an established standard. The standard - is also begining to be adopted by other specifications such as the - Servlet - 2.3 API. Thus we are likely to see an increase of jars using this mechanism - to specify dependencies. -

- -

The "Optional Package" mechanism allows jars to specify dependencies on other - jars that implement a particular specification at particular version levels. For - example you could specify a dependency on the Trax 1.1 API by adding the following - to the manifest of your jar.

- - -Extension-List: trax -trax-Extension-Name: Java API for XML Parsing -trax-Specification-Version: 1.1 - - -

In some cases you may also wish to specify a dependency on a specific vendors - implementation. For instance you may need to use xalan due to it implementing a - particular extension you need. In that case you manifest may contain;

- - -Extension-List: trax -trax-Extension-Name: Java API for XML Parsing -trax-Specification-Version: 1.1 -trax-Implementation-Title: org.apache.xalan.xslt -trax-Implementation-Version: 2.1.0 -trax-Implementation-Vendor: Apache Software Foundation - - -

In many cases there will be no distinction between the specification and - the implementation of a library. For instance the Velocity project only has - one implementation and one specification. In which case it is sufficient to - just declare a dependency on the Velocity "Specification". A library that uses - both the Trax API and the Velocity project may look like;

- - -Extension-List: trax velocity -velocity-Extension-Name: org.apache.velocity -velocity-Specification-Version: 1.0 -trax-Extension-Name: Java API for XML Parsing -trax-Specification-Version: 1.1 -trax-Implementation-Title: org.apache.xalan.xslt -trax-Implementation-Version: 2.1.0 -trax-Implementation-Vendor: Apache Software Foundation - - -

To make other jars available to Ant libraries as "Optional Packages" - or Extensions then you need to add a few lines to the manifest of the - other jar. The minimal manifest is the following;

- - -Extension-Name: org.realityforge.dve -Specification-Vendor: Peter Donald -Specification-Version: 1.0 - - -

It is important to note that looking for dependencies is recursive. For example, - if the ant library depends upon jar A and and A depends on B then both A and B will - need to be loaded by the container.

- - - - - -

So far there has been no mention of implementation strategies for - managing ClassLoaders and other details about where the "Optional Packages" - are stored. This section will outline such details but they could change - in the future. The above specification will still be accurate but the approach - to implementing specification will be different.

- -

In the current architecture all of the "Optional Packages" are assumed to - be stored in the - $ANT_HOME/ext directory. The runtime will scan - this directory for jars and add all the "optional Packages" found into a - registry. This registry will be used by the library loading mechanism to locate - all the "Optional Packages". The user is able to specify an alternative directory - or add a new directory to search on the commandline. -

- -

When the container attempts to load an ant library it will also try to load - any needed dependencies. First it will check the parent ClassLoaders to see if any - of them contain the required dependencies. If not then it will search the - "Optional Packages" registry. If the dependency is not found then a error will be - signaled. If the dependency is found in the "Optional Packages" registry then it is - loaded by the same ClassLoader that is used to load the Ant library.

- - - -
- - - diff --git a/proposal/myrmidon/src/xdocs/stylesheets/docs.vsl b/proposal/myrmidon/src/xdocs/stylesheets/docs.vsl deleted file mode 100644 index 4d973af89..000000000 --- a/proposal/myrmidon/src/xdocs/stylesheets/docs.vsl +++ /dev/null @@ -1,91 +0,0 @@ - - - - - ## Defined variables - #set ($bodybg = "#ffffff") - #set ($bodyfg = "#000000") - #set ($bodylink = "#525D76") - #set ($bannerbg = "#525D76") - #set ($bannerfg = "#ffffff") - #set ($subbannerbg = "#828DA6") - #set ($subbannerfg = "#ffffff") - #set ($tablethbg = "#039acc") - #set ($tabletdbg = "#a0ddf0") - - -#document() - - -## This is where the common page macro's live - -#macro ( subsection $subsection) - - - -
- - #if ( $subsection.getAttributeValue("anchor") ) - #set ($anchor = $subsection.getAttributeValue("anchor")) - #else - #set ($anchor = $subsection.getAttributeValue("name")) - #end - $subsection.getAttributeValue("name") - -
-
- #foreach ( $items in $subsection.getChildren() ) - #if ($items.getName().equals("img")) - #image ($items) - #elseif ($items.getName().equals("source")) - #source ($items) - #elseif ($items.getName().equals("table")) - #table ($items) - #else - $xmlout.outputString($items) - #end - #end -
-
-#end - -#macro ( section $section) - - - -
- - #if ( $section.getAttributeValue("anchor") ) - #set ($anchor = $section.getAttributeValue("anchor")) - #else - #set ($anchor = $section.getAttributeValue("name")) - #end - $section.getAttributeValue("name") - -
-
- #foreach ( $items in $section.getChildren() ) - #if ($items.getName().equals("img")) - #image ($items) - #elseif ($items.getName().equals("source")) - #source ($items) - #elseif ($items.getName().equals("table")) - #table ($items) - #elseif ($items.getName().equals("subsection")) - #subsection ($items) - #else - $xmlout.outputString($items) - #end - #end -
-
-#end - -#macro (document) - #header() - #set ($allSections = $root.getChild("body").getChildren("section")) - #foreach ( $section in $allSections ) - #section ($section) - #end - #footer() -#end diff --git a/proposal/myrmidon/src/xdocs/stylesheets/project.xml b/proposal/myrmidon/src/xdocs/stylesheets/project.xml deleted file mode 100644 index 2dbeb2263..000000000 --- a/proposal/myrmidon/src/xdocs/stylesheets/project.xml +++ /dev/null @@ -1,34 +0,0 @@ - - - Apache Myrmidon - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/proposal/myrmidon/src/xdocs/stylesheets/templates.vm b/proposal/myrmidon/src/xdocs/stylesheets/templates.vm deleted file mode 100644 index 708e8e90d..000000000 --- a/proposal/myrmidon/src/xdocs/stylesheets/templates.vm +++ /dev/null @@ -1,197 +0,0 @@ -## This is where the common macro's live - -#macro ( table $table) - - #foreach ( $items in $table.getChildren() ) - #if ($items.getName().equals("tr")) - #tr ($items) - #end - #end -
-#end - -#macro ( tr $tr) - - #foreach ( $items in $tr.getChildren() ) - #if ($items.getName().equals("td")) - #td ($items) - #elseif ($items.getName().equals("th")) - #th ($items) - #end - #end - -#end - -#macro ( td $value) - #if ($value.getAttributeValue("colspan")) - #set ($colspan = $value.getAttributeValue("colspan")) - #end - #if ($value.getAttributeValue("rowspan")) - #set ($rowspan = $value.getAttributeValue("rowspan")) - #end - - - #if ($value.getText().length() != 0 || $value.hasChildren()) - $xmlout.outputString($value, true) - #else -   - #end - - -#end - -#macro ( th $value) - #if ($value.getAttributeValue("colspan")) - #set ($colspan = $value.getAttributeValue("colspan")) - #end - #if ($value.getAttributeValue("rowspan")) - #set ($rowspan = $value.getAttributeValue("rowspan")) - #end - - - #if ($value.getText().length() != 0 || $value.hasChildren()) - $xmlout.outputString($value, true) - #else -   - #end - - -#end - -#macro ( projectanchor $name $value ) - #if ($value.startsWith("http://")) - $name - #elseif ($value.startsWith("/site")) - $name - #else - $name - #end -#end - -#macro ( metaauthor $author $email ) - - -#end - -#macro ( image $value ) - #if ($value.getAttributeValue("width")) - #set ($width=$value.getAttributeValue("width")) - #end - #if ($value.getAttributeValue("height")) - #set ($height=$value.getAttributeValue("height")) - #end - #if ($value.getAttributeValue("align")) - #set ($align=$value.getAttributeValue("align")) - #end - -#end - -#macro ( source $value) -
- - - - - - - - - - - - - - - - - 
$escape.getText($value.getText())
-
-#end - -#macro ( makeProject ) - #set ($menus = $project.getChild("body").getChildren("menu")) - #foreach ( $menu in $menus ) -

$menu.getAttributeValue("name")

-
    - #foreach ( $item in $menu.getChildren() ) - #set ($name = $item.getAttributeValue("name")) -
  • #projectanchor($name $item.getAttributeValue("href"))
    • - #end -
- #end -#end - -#macro (getProjectImage) - #if ($project.getChild("logo")) - - - - - #set ( $logoString = $project.getChild("logo").getAttributeValue("href") ) - #if ( $logoString.startsWith("/") ) - $project.getChild( - #else - $project.getChild( - #end - - #else - - - - #end -#end - -#macro (header) - - - - - #set ($authors = $root.getChild("properties").getChildren("author")) - #foreach ( $au in $authors ) - #metaauthor ( $au.getText() $au.getAttributeValue("email") ) - #end - - $project.getChild("title").getText() - $root.getChild("properties").getChild("title").getText() - - - - - - - - - -
#getProjectImage()
$project.getChild("title").getText()
- - - - - - - - - - - - -
-
-
- #makeProject() - -#end - -#macro (footer) -
-
-
-
- Copyright © 2000-2002, Apache Software Foundation -
-
- - -#end diff --git a/proposal/myrmidon/src/xdocs/task.xml b/proposal/myrmidon/src/xdocs/task.xml deleted file mode 100644 index dcb53e916..000000000 --- a/proposal/myrmidon/src/xdocs/task.xml +++ /dev/null @@ -1,112 +0,0 @@ - - - -Peter Donald -My First Task - - - - -
- -

In Ant 1 it was very easy to write your own task. In Ant 2 we plan -to make it even easier. To write a basic task simply follow the following -formula.

- -
    -
  1. - Create a Java class that extends - org.apache.myrmidon.api.AbstractTask -
    2. -
  2. - For each attribute, write a setter method. The setter method - must be a public void method that takes a single argument. The name - of the method must begin with "set", followed by the attribute name, with - the first character of the name in uppercase, and the rest in lowercase. - The type of the attribute can be: -
      -
    • String
      • -
    • - Any primitive type - they are converted for you from their - String-representation in the buildfile -
      • -
    • - File - the string representation will be interpreted relative to - the project's basedir. -
      • -
    -
    3. -
  3. - For each nested element create a public void method that takes a single - argument. The name of the method must begin with "add", followed by the - attribute name, with the first character of the name in uppercase, and - the rest in lowercase. The type of the parameter is an object with a - no-arguement constructor. It is configured in exactly the same was a - task is configured (via setters and adders) and then added to the task. -
    4. -
  4. - Write a public void method named "execute" with no arguments that - throws a TaskException. This is the method called to do the - actual work of the task. -
    5. -
- - - -

So a basic task that has one attribute named "message" and just prints -out this message is as simple as;

- - -package org.realityforge.tasks; - -import org.apache.myrmidon.api.AbstractTask; -import org.apache.myrmidon.api.TaskException; - -public class SystemOutPrinterTask - extends Task -{ - private String m_message; - - // The setter for the "message" attribute - public void setMessage( final String message ) - { - m_message = message; - } - - // The method executing the task - public void execute() - throws TaskException - { - System.out.println( m_message ); - } -} - - -

To use this task you could create a library but instead we will -just use <taskdef> to define the task. An example usage would be;

- - - - - - - - - - - - -]]> - - - - - -
- - - diff --git a/proposal/myrmidon/src/xdocs/todo.xml b/proposal/myrmidon/src/xdocs/todo.xml deleted file mode 100644 index fc0d79228..000000000 --- a/proposal/myrmidon/src/xdocs/todo.xml +++ /dev/null @@ -1,565 +0,0 @@ - - - - Adam Murdoch - Peter Donald - Get Involved - - - - -
- -

The broad goal is to grow Myrmidon from a prototype task engine into a fully - fledged build system, that can serve as the basis for Ant 2. The following - sections describe some of the many things which still need to be done to - achieve that goal. This list is currently under construction.

- - - - -

Integrate with the XDocs proposal that generates XML documentation for - tasks. Rework that proposal so that it knows about the Myrmidon specific - patterns and features. Also rework it so that it can support reading - documentation and examples from side-by-side the task.

- - - -

Consider allowing task writers to write their own TaskInfo objects - (or at least have them generated from XDoclet directives). This would - encompass both documentation and perhaps introspection of the types.

- - - -

- 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. -

- - - -

Much like Exec should be decoupled from Ant runtime, so should classes - to implement java task for the same benefits.

- - - -

- 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. -

-

- 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 foo.c actually depends upon foo.h, bar.h - and baz.h. 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; -

- -public interface DependencyGenerator -{ - File[] generateDependencies( File file ); -} - -

- 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 foo.c may declare that - it is dependent upon foo.h, bar.h and baz.h, 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. -

-

- A possible API would be -

- -DependencyManager dm = ...; -dm.setFileSet( myFileSet ); -dm.setDependencyCache( myDependencyCacheFile ); -File[] files = cm.getOutOfDate(); - - - - -

After a templating system is formalized it would useful to define - a mechanism via which you can store templates in an antlib. These - templates could then be loaded and used by build files through a - "standard" mechanism. This may need to be merged with the XML catalog - system.

- - - -

Add a system via which ant libs can store general resources for - consumption by build users. This could be used to store the XML fragments - for the XML catalog, the template fragments for templates, images for - documentation system and so forth.

- - - -

- 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 Foo.java, it may depend on the Bar.java - 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 Foo.java file was compiled with - debug="true" last run and this time needs to be compiled with - debug="false" then it is out of date and needs to be recompiled. We call this - "environmental" dependency information "coloring". -

-

- 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. -

-

- An API for such a bean has yet to be established but an example API would be. -

- -ColoringManager cm = ...; -cm.addColor( "debug", "true" ); -cm.addColor( "optimize", "false" ); -cm.setFileSet( myFileSet ); -File[] files = cm.getOutOfDate(); - - - - - -

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.

-

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.

- - - - - -

We need to rethink the whole notificaiton scheme. Should tasks be able to - raise events? Probably as long as we have ContainerTasks. Should tasks - be able to query state of run? ie Can a task request "are we paused?" or "are we - stopped?" ? Probably as that way long running tasks are given the opportunity - to be gracefully halted by the end users (primarily aimed at IDE vendors here).

- - - - - -

Most tasks are grouped into some sort of task container. The task containers - can be things like workspaces, projects, targets or other tasks. Each of these - containers usually has a name. Thus we could refer to tasks via a path such as - "/avalon/compile/javac" would refer to the task "javac" in the target "compile" - in the project "avalon". In the past it has been requested that a task get access - to this path programatically - other people have also asked for access to things - like the currently running target. We need to assess this and decide whether we - wish to support it.

- -

Another point to think about is that we could use XPath-like string to designate - to other tasks to execute. ie antcall would refer to a path rather than a target name

- - - - - -

Assigned To: Peter

-

Write a HOWTO describing how to embed Myrmidon into other - applications.

- - - - - -

Assigned To: Peter

-

Extend Myrmidons library management facilities so that optional - dependencies may be declared for a library. ie The library will still - operate in absence of such libraries but can provide further features - if these libraries are present. Most likely this will be done via a - new manifest entry "Optional-Extension-List:" that behaves similar - to "Extension-List:" except that the extensions are optional.

- - - - - -

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 have a base - class that is meant to facilitate this sort of task and make it easy to develope. See - AbstractFacadeTask. However we need to write up a HOWTO so people can use it.

- - - - - -

Convert the Ant 1.x Mail tasks to Myrmidon.

- - - - -

Add the ability to run java programs that call System.exit() by adding a - security manager. Should look something like:

- -public class MyrmidonSecurityManager - extends SecurityManager -{ - public void checkExit( final int status ) - { - throw new ExitException( status ); - } - - public void checkPermission( final Permission permission ) - { - } -} - - - - - -

Myrmidon must be able to build itself. Currently, it is built using - Ant 1.x. Ultimately, Myrmidon should be able to build itself from exactly the - same build file. To start with, however, there is no need for Myrmidon to be - able to do this. Myrmidon should also be able to be bootstrapped (that is, be - able to be built from scratch, without using Ant 1.x at all).

- - - - - -

Consider calling validate() on task prior to execute(). This would allow - us to have a "make -k" mode that actually did basic validation and would also - encourage task writers to do validation properly.

- - - - - -

Consider allowing the user to configure the ant system by setting the - following path types.

-
    -
  • ant.type.path: path that is used to search for the type libraries
    • -
  • ant.ext.path: path that is used to search for "Optional Packages" - or extensions.
    • -
-

- The default search path will probably include a per-user path element, - a workspace path element and a system path elemtn that are searched in - that order. Some possible defaults; -

-
    -
  • Unix Per-user: ${user.home}/.ant/lib, ${user.home}/.ant/ext
    • -
  • Windows Per-user: ${user.home}/ant/lib, ${user.home}/ant/ext
    • -
  • MacOSX Per-user: ${user.home}/Library/Ant/lib, - ${user.home}/Library/Ant/ext
    • -
  • Unix System-wide: /opt/ant/lib, /opt/ant/ext
    • -
  • Unix System-wide: /usr/local/ant/lib, /usr/local/ant/ext
    • -
  • Windows System-wide: %SYS_DRIVE%/Program Files/ant/lib, - %SYS_DRIVE%/Program Files/ant/ext
    • -
  • MacOSX System-wide: /Library/Ant/lib, /Library/Ant/ant/ext
    • -
- - - - -

The Ant 1 Compatibility layer is still in early stages of development. -

-
    -
  • Get a version of <antcall> working.
    • -
  • - Provide hooks between Ant 1 references and Myrmidon properties. - May use converters for adapting Ant 2 objects (like Ant 2 - <path> or <fileset>) - as Ant 1 types. -
    • -
  • - Missing tests: -
      -
    • Make sure properties are shared between Ant 1 and Myrmidon tasks.
      • -
    -
    • -
  • Get GUMP runs going using Myrmidon.
    • -
  • Add protected accessors for get/set/list properties in - Ant 1 Project, to minimise the amount of code duplication in - Ant1CompatProject.
    • -
- - - - -

The VFS needs plenty of work:

- -
    -
  • Move files/folders.
    • -
  • Recursive folders copy.
    • -
  • Search through a file hierarchy, using Ant-style wildcards.
    • -
  • Search through a file hierarchy, using a Selector interface.
    • -
  • The in-memory caching mechanism is pretty rudimentary at this stage. - It needs work to make it size capped. In addition, some mechanism needs - to be provided to release and refresh cached info. -
    • -
  • Convert files/folders into local files, for handing off - to external commands, or legacy tasks.
    • -
  • Refactor the replication mechanism out of ZipFileSystemProvder, - and make more general pluggable.
    • -
  • Capabilities discovery.
    • -
  • Attributes and attribute schema.
    • -
  • Handle file canonicalisation better (for cases like case-insensitive - file systems, symbolic links, name encoding, etc).
    • -
  • File system layering. That is, the ability for a file system to - sit on top of another file system, or a file from another file system - (e.g. Zip/Jar/Tar file systems, gzip/encoding file systems, virtual file - systems). -
    • -
- - - - - -

The file data-types, such as - <fileset> and - - <path>, are some of the most widely used parts of Ant 1.x. - Unfortunately, they aren't particularly extensible. -

- -
    -
  • Redesign the file data-types, replacing them with an interface-based - API, plus a set of implementations. The API should use the VFS file - - FileObject, rather than - java.io.File. - This process has started, in the - antlib.vfile package. - -
    • -
  • File Selectors: - -
      -
    • Change - AbstractNameFileSelector to use Ant 1 style patterns - matches, rather than Globs patterns. -
      • -
    • Add 'defaultexcludes' to - DefaultFileSet. Also add a - file selector implementation that matches everything except the default - excludes. -
      • -
    • Add a name selector that loads patterns from a file.
      • -
    • Add more selector implementations: size and last-modified comparisons, - checksum comparison, byte-wise content comparison.
      • -
    -
    • -
  • File conditions: - -
      -
    • Add more condition implementations that perform checks on files. - One that searches a path for a file would be useful.
      • -
    -
    • -
  • File Name Mappers: - -
      -
    • Change FileNameMapper.mapFileName() to take vfs.FileName objects.
      • -
    • Move the current mapper implementations across to antlib.
      • -
    -
    • -
  • File Sets: - -
      -
    • Add a file set implementation that provides the union of several - nested file sets (that is, a file set that merges several file sets - together).
      • -
    • Add a file set implementation that filters files that are up-to-date - WRT some other file. Alternatively, this might be better done as a - file selector.
      • -
    -
    • -
  • Paths: - -
      -
    • Add path implementations that evaluate to the system classpath, - and the ant runtime classpath. Or, more generally, combine this with - - ClassLoaderManager to evaluate to the classpath of any - 'library' (e.g. system classpath, ant runtime, tools.jar, - an antlib, an installed extension, or the system classes of another JVM - for cross-compiling). -
      • -
    -
    • -
  • Port across the Ant 1 file filter proposal, once it is complete.
    • -
  • Copy task: - -
      -
    • Implement 'preservelastmodified', 'overwrite', and 'includeemptydirs'.
      • -
    • Support a file name mapper.
      • -
    • Support file filters.
      • -
    • Detect and handle destination file name collisions.
      • -
    -
    • -
  • Implement the - <move>, - <delete>, - - <touch> and - <mkdir> tasks on top - of the VFS and the new file data-types. Might be some scope for generalising - 'touch' and 'mkdir' into a single task. -
    • -
- - - - - -

One of the goals of Ant 2 is to allow the user to easily customise and - extend Ant. The command-line and local configuration files, are two places - where this would be done. Currently, Myrmidon some customisation from the - command-line, but does not support configuration files.

- -
    - -
  • Load configuration from system (from $ANT_HOME) and user (from $HOME) - configuration files.
    • - -
  • Allow the following via config files: - -
      -
    • Add (or override) the - lib and - ext directories. -
      • -
    • Enable more than one listener, and configure the listeners from - the conents of the config file.
      • -
    • Import libraries, and set properties.
      • -
    • Execute tasks.
      • -
    • Install and configure runtime services.
      • -
    -
    • - -
- - - - -

Add the ability to extend Ant using languages other than - Java:

-
    -
  • Define a task using a scripting language such as Javascript.
    • -
  • Use Rhino's ability to implement Java interfaces, to - implement and define types, such as FileSelector, or - Condition.
    • -
  • Define a task using template.
    • -
  • Add some lightweight scripting tasks.
    • -
- - - - -

Everyone loves writing documentation, and so a goal for Ant 2 is to - generate a lot of reference documentation for tasks and other types directly - from the source. Unfortunately, there's still plenty of tutorial material - to write. In particular we need these:

- -
    -
  • User documentation - describing things like the build file format, - how properties work, how to use references, how sub-builds work, how to customise - Myrmidon, and so on.
    • - -
  • Task writer documentation - describing things like an overview the task API, - how configuration works, task lifecycle, how to assemble an antlib, a catalog - of the runtime services, and so on.
    • - -
  • Myrmidon developer documentation - a broad outline of the architecture, - how to build, how to test, and so on. Also, this todo list needs plenty - of filling out.
    • - -
- - - - - -

A completely unordered list of items, big and small:

- -
    -
  • Search through the code for 'TODO' items and fix them.
    • -
  • Allow service factories to be configured from the contents of the - - ant-services.xml descriptor. -
    • -
  • Add verbosity level to ProjectListener LogEvent
    • -
  • Fire ProjectListener events taskFinished(), targetFinished() and - projectFinished() events on build failure, adding indicator methods to - ProjectEvent.
    • -
  • Fire ProjectListener events projectStarted() and projectFinished() - events on start and finish of referenced projects, adding indicator methods - to ProjectEvent.
    • -
  • Detect duplicate type names.
    • -
  • Add fully qualified type names, based on antlib name and type shorthand name. - Allow these to be used in build files in addition to the shorthand names.
    • -
  • Move the - <http> and - <socket> - conditions to an antlib. Need to resolve how these will be passed a logger. -
    • -
  • Add an else block to the - <if> task. -
    • -
  • Move - crimson.jar to - bin/lib in the distribution, - and make available to other jars via the extension mechanism. -
    • -
  • Change DefaultPropertyResolver to ignore '$${'.
    • -
  • Add a --type command-line option, to allow - the project builder to be manually selected. -
    • -
  • Change ProjectBuilder - and Embeddor to throw something more - specialised than Exception. -
    • -
  • Change DefaultClassLoaderManager to handle - directories as part of a library classpath. -
    • -
  • <condition> should set the property - value to false when the condition is false.
    • -
  • Split the <uptodate> condition into - a condition that checks against a single target file, - and one which checks using a destdir/mapper.
    • -
  • Add condition implementations to: check JVM version, - check Ant version, check whether a particular antlib or extension is - available, match a string against a regular expression.
    • -
  • Add a task to unset a property.
    • -
  • Change the various def and import task to allow a classpath - to be provided.
    • -
  • Unit tests.
    • -
- - - -
- - - diff --git a/proposal/myrmidon/src/xdocs/user.xml b/proposal/myrmidon/src/xdocs/user.xml deleted file mode 100644 index e32905dbb..000000000 --- a/proposal/myrmidon/src/xdocs/user.xml +++ /dev/null @@ -1,118 +0,0 @@ - - - -Adam Murdoch -User Guide - - - - -
- -

-First, you will need to fetch the Myrmidon source from CVS. The source -can be found in the proposal/myrmidon directory of the -Ant source tree. You should check out the jakarta-ant CVS -module, as described -here. -

- -

-To build Myrmidon, use the build.xml build script. You will need -to use Ant 1.4.1 or later. The default target builds the Myrmidon distribution -into the dist directory. The distribution is a ready-to-run -installation of Myrmidon. -

- -

There are a number features that are not built unless the appropriate optional Jar -files are found in the lib directory:

- - - - - - - - - - - - - -
FeatureJar FileDownload From
SMB VFS support (Samba, Windows shares)jcifs.jarjcifs.samba.org. -

Note: there are problems using the 0.6.1 release. Try 0.6.0 instead.

FTP VFS supportnetcomponents.jarwww.savarese.org
- -
- -
- -

-To run Myrmidon, use one of the following methods: -

- - - -

-On Windows and Unix platforms, you can use the ant script -in the distribution's bin directory. The following environment -variables can be used, but are not required (except on Windows 9x - see below). -

- -

- -

- - - - - - - - - - - - - - - -
VariableDescription
JAVA_HOMEThe directory that the JDK is installed in.
JAVACMDThe command to use to start the JVM. Defaults to java.
ANT_HOME - The directory containing the Myrmidon distribution. This must be - set when running on Windows 95, 98 or Me. -
- - - - - -

-The Myrmidon distribution includes an executable Jar file, which can be used -to run Myrmidon. Use the following command: -

-
-prompt> java -jar ant-home/bin/myrmidon-launcher.jar options
-
- - - -

When started, Myrmidon looks for a project file called build.ant -in the current directory. A different project file can be specified using the --f command-line option. Myrmidon executes the targets that are -listed on the command-line, or the default target if none is given. For -example, the following command executes targets clean and -build from project file my-project.xml:

- -
-prompt> ant -f my-project.xml clean build
-
- -

-Run Myrmidon with the -h command-line option for a list of -the command-line options that are available. -

- -
- - - - diff --git a/proposal/myrmidon/src/xdocs/velocity.properties b/proposal/myrmidon/src/xdocs/velocity.properties deleted file mode 100644 index 06943b256..000000000 --- a/proposal/myrmidon/src/xdocs/velocity.properties +++ /dev/null @@ -1,2 +0,0 @@ -file.resource.loader.path=src/xdocs/stylesheets -velocimacro.library=templates.vm diff --git a/proposal/myrmidon/src/xdocs/vfs.xml b/proposal/myrmidon/src/xdocs/vfs.xml deleted file mode 100644 index 707e989d8..000000000 --- a/proposal/myrmidon/src/xdocs/vfs.xml +++ /dev/null @@ -1,218 +0,0 @@ - - - - Adam Murdoch - VFS User Guide - - - - -
- -

Myrmidon includes a Virtual File System (VFS), which allows files from - different sources to be treated identically. The VFS currently supports - the following file types:

- - - - - - - - - - - - - - - - - - - - - - - -
File SystemDescriptionURL Format
Local FilesFiles on the local file system.Three different formats are currently supported for local file names: -
    -
  • file:// absolute-file-name
    • -
  • Absolute file names
    • -
  • Relative file names. These are resolved relative to the - project's base directory. -
    • -
-
Zip FilesThe contents of Zip files (and Jar, War, and Ear files). - Currently, the VFS supports read-only access to Zip file contents.zip: zip-file-uri [!absolute-path]
FTPFiles on an FTP server.ftp:// [[password:] username@] hostname [:port] [absolute-path]
SMBFiles on a CFIS server, such as Samba or Windows shares.smb:// [[password:] username@] hostname [:port] [absolute-path]
- -

Both forward or backward slashes can be used to separate the elements of - a URL.

- -

Here are some example URLs:

- -
    -
  • build/classes
    • -
  • c:\program files\ant\bin
    • -
  • file://C:/program files/ant
    • -
  • zip:build/lib/ant.jar!/org/apache/tools
    • -
  • ftp://adam@somehost/pub/downloads
    • -
  • smb://password:adam@somehost/home/adam
    • -
- -

Currently, there are only a handful of VFS aware tasks. This will grow - as more tasks are ported to the new API, and data types.

- - - -

A file set in Myrmidon is more general than Ant 1's concept of a file set. - Firstly, there is more than one type of file set. Secondly, they are VFS enabled. - File sets are automatically converted to a path, and so - can be used anywhere that a path can.

- -

<v-fileset>

- -

This is the equivalent of Ant 1's <fileset> (The name - is temporary, it will be changed to <fileset> once more - porting work as been completed).

- -

Rather than use a set of include and exclude patterns to choose the files - that make up the file set, <v-fileset> takes zero or more - file selectors. File selectors can be used to - select files based on any attribute of the file, rather than just the name. - You can use <name> selectors to achieve the same result - as using includes or excludes.

- -

A <v-fileset> element takes the following attributes:

- - - - - - - - -
AttributeDescriptionDefault Value
dirThe base directory for the file set. This can be any URL that the - VFS supports.Required
- -

A <v-fileset> element takes any number of nested - file selector elements. To be included in the - file set, a file must be selected by all the file selectors. That is, the - file selectors are implicitly AND-ed together. If no file selector is provided, - all the files and directories are included in the set.

- -

An example:

- - - - - -]]> - -

<flat-fileset>

- -

This file set takes a set of nested file sets and paths, and flattens them - into a single directory. It can be used as a way of converting a path into a - file set. It can also be used as a replacement for the flatten - attribute for the copy and move tasks.

- -

A <flat-fileset> element takes no attributes, and a set - of nested paths or file sets.

- -

An example:

- - - - - - - - - -]]> -

<mapped-fileset>

- -

A fileset that applies a file name mapper - to a nested fileset. -

- - - - - -

Paths are an ordered list of files.

- -

<v-path>

- -

This is the equivalent of Ant 1's <path>.

- -

<filtered-path>

- -

A path that applies file selectors to a set of nested file sets and paths.

- - - - - -

File selectors are used to select files from file sets and paths.

- -

<and>

- -

Combines zero or more file selectors, using AND. An empty <and> - selector accepts all files.

- -

<basename>

- -

Selects files whose base name matches an Ant 1 style pattern, or a regular - expression.

- -

<condition>

- -

Takes a set of conditions. If - the conditions evaluate to true, then select every file. Otherwise, - select no files.

- -

<exists>

- -

Selects files that exist.

- -

<is-empty-folder>

- -

Selects empty folders, that is, folders that have no children.

- -

<is-folder>

- -

Selects folders, does not select regular files.

- -

<is-file>

- -

Selects regular files, does not select folders.

- -

<name>

- -

Selects files whose path in a file set matches an Ant 1 style pattern, or - a regular expression.

- -

<not>

- -

Selects files that are not selected by a nested file selector.

- -

<or>

- -

Combines zero or more file selectors, using OR. An empty <or> - selector accepts all files.

- -

<url>

- -

Selects files whose URL matches an Ant 1 style pattern, or a regular expression.

- - - -
- - -