- The Myrmidon-Ant1 Compatibility layer works by reusing most of the Ant1 code,
+ 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 Ant1 tree
+ 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 Ant1 tree, Ant1 class files are extracted from a jar, rather than
+ 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 Ant1 task is encountered, an Ant1
+ 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 Ant1 versions of Task and Project have been extended, overriding core behaviour,
+ 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 Ant1 configuration policy, although not all of the
- subtle variations of configuration present in Ant1 are handled.
+ 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,
@@ -114,16 +114,16 @@
Task defined by <taskdef> (done)
- So at present, properties declared in Ant2 tasks are available to all Ant1 tasks,
+ 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 Ant2 tasks in the same build, and vice-versa.
+ 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 Ant1 version of TypeInstanceTask in the descriptor.
+ the Ant 1 version of TypeInstanceTask in the descriptor.
The TransformingProjectBuilder (which is now the default builder for files
@@ -137,7 +137,7 @@
If you have a Myrmidon build file (eg with version="2.0"
- on the project element, you can use Ant1 tasks and datatypes by using
+ 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 Ant1.4.1 are available
+ Virtually all tasks and datatypes from Ant 1.4.1 are available
in this way.
- Myrmidon will automatically handle Ant1 build files using the
- Ant1 Compatibility layer. So, using an Ant1 build
+ 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 Ant1 build file. So all tasks are
+ 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.
Before building the Ant1 Compatibility layer, you need to build
+
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.
-The project file format is very similar to that of Ant 1. The root element of
-the project file must be a <project> element. It can
-take the following attributes:
+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:
@@ -125,7 +131,7 @@ take the following attributes:
- The base-name of the project file, with the extension removed.
+ The name of the project file, with the extension removed.
@@ -181,7 +187,7 @@ take the following attributes:
- The project file version that the project is written for.
+ The project file format version that the project is written for.
<project> element can contain the following elements,
in the order given below:
@@ -276,7 +282,7 @@ A <projectref> element takes the following attributes:
The targets of a referenced project can be used in the depends list
-of a target in the referencing project, using the following syntax:
+of a target in the referencing project, using the syntax
project-name->target-name. Here is a simple example:
@@ -314,7 +320,7 @@ of a target in the referencing project, using the following syntax:
Implicit tasks are run before any of the project's targets are run. Any task
-can be used, including <property> and data-type instances.
-Implicit tasks can be used to initialise the project. For example:
+
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:
@@ -495,7 +501,7 @@ Implicit tasks can be used to initialise the project. For example:
In many ways Ant2 needs to follow rules similar to a number of
+
In many ways Ant 2 needs to follow rules similar to a number of
different application servers with respect to ClassLoader management.
- Ant2 will create a number of different ClassLoaders that have access
+ 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
@@ -97,7 +97,7 @@
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 Ant2 is as
+
Using kooky ascii art, the specific ClassLoader structure for Ant 2 is as
follows:
@@ -146,7 +146,7 @@
The
Common ClassLoader contains the classes and resources
- that are made visible to both the Container and to all the ant type librarys. This
+ 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;
@@ -172,7 +172,7 @@
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 ant2 versions.
+ notice between between different Ant 2 versions.
@@ -188,7 +188,7 @@
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 librarys as they implement
+ 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
@@ -198,7 +198,7 @@
The
Shared ClassLoader contains all the classes and resources
- that are shared across all of the ant librarys (unless they are als needed by the
+ 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
diff --git a/proposal/myrmidon/docs/configuring.html b/proposal/myrmidon/docs/configuring.html
index af08c98b6..67e0a7828 100644
--- a/proposal/myrmidon/docs/configuring.html
+++ b/proposal/myrmidon/docs/configuring.html
@@ -11,7 +11,7 @@
- Apache Myrmidon - On Task Configuring in Ant2
+ Apache Myrmidon - On Task Configuring in Ant 2
@@ -46,13 +46,13 @@
There are plenty of things you can do to help out with Myrmidon. The Todo
- list below 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.
+
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:
Myrmidon is a proposal for Ant 2. Ant2 is the next evolution of the
- Ant build tool aimed at removing many of the limitations of the Ant1.x
+
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
@@ -118,7 +118,7 @@
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 ant1.x but prohibitively difficult).
+ 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.
@@ -131,14 +131,14 @@
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.
+ and install tools based on the Myrmidon base.
Long ago there was identified the need for librarys that contain
+
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 Ant2. The librarys (also referred to as
+ defined and used in Ant 2. The libraries (also referred to as
deployments) will be termed antlibs.
-
Ant librarys can be packaged and signed into a ANt Type Library
+
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
@@ -103,7 +103,7 @@
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 librarys or resources
+
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
@@ -123,7 +123,7 @@
@@ -163,7 +163,7 @@
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.
-
Ant2 uses the "Optional Package" mechanism. Prior to JDK1.3, an "Optional
+
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
@@ -269,7 +269,7 @@ trax-Implementation-Vendor: Apache Software Foundation
-
To make other jars available to Ant librarys as "Optional Packages"
+
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;
Integrate with the XDocs proposal that generates XML documentation for
- tasks. Rework that proposal so that it knows about the myrmidon specific
+ 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.
The Ant1 Compatibility layer is still in early stages of development.
+
The Ant 1 Compatibility layer is still in early stages of development.
Get a version of <antcall> working.
- Provide hooks between Ant1 references and Myrmidon properties.
- May use converters for adapting Ant2 objects (like Ant2
+ Provide hooks between Ant 1 references and Myrmidon properties.
+ May use converters for adapting Ant 2 objects (like Ant 2
<path> or <fileset>)
- as Ant1 types.
+ as Ant 1 types.
Missing tests:
-
Make sure properties are shared between Ant1 and Myrmidon tasks.
+
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
- Ant1 Project, to minimise the amount of code duplication in
+ Ant 1 Project, to minimise the amount of code duplication in
Ant1CompatProject.
@@ -587,7 +587,7 @@ public class MyrmidonSecurityManager
@@ -837,9 +837,6 @@ public class MyrmidonSecurityManager
<socket>
conditions to an antlib. Need to resolve how these will be passed a logger.
-
Allow the
- <if> task to take any condition implementation.
-
Add an else block to the
<if> task.
@@ -860,11 +857,16 @@ public class MyrmidonSecurityManager
directories as part of a library classpath.
<condition> should set the property
- value to false when the condition is false.
+ 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.
+ 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.
First, you will need to fetch the Myrmidon source from CVS. The source
-can be source in the proposal/myrmidon directory of the
+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.
@@ -167,7 +167,7 @@ files are found in the lib directory:
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 given on
-the command-line, or the default target if none is given. For example, the
-following executes the targets clean and build from
-the project file my-project.xml:
+-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:
- The Myrmidon-Ant1 Compatibility layer works by reusing most of the Ant1 code,
+ 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 Ant1 tree
+ 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 Ant1 tree, Ant1 class files are extracted from a jar, rather than
+ 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 Ant1 task is encountered, an Ant1
+ 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 Ant1 versions of Task and Project have been extended, overriding core behaviour,
+ 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 Ant1 configuration policy, although not all of the
- subtle variations of configuration present in Ant1 are handled.
+ 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,
@@ -40,17 +40,17 @@
- So at present, properties declared in Ant2 tasks are available to all Ant1 tasks,
+ 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 Ant2 tasks in the same build, and vice-versa.
+ 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 Ant1 version of TypeInstanceTask in the descriptor.
+ the Ant 1 version of TypeInstanceTask in the descriptor.
@@ -62,12 +62,12 @@
-
+
If you have a Myrmidon build file (eg with version="2.0"
- on the project element, you can use Ant1 tasks and datatypes by using
+ 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 Ant1.4.1 are available
+ Virtually all tasks and datatypes from Ant 1.4.1 are available
in this way.
@@ -78,16 +78,16 @@
-
+
- Myrmidon will automatically handle Ant1 build files using the
- Ant1 Compatibility layer. So, using an Ant1 build
+ 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 Ant1 build file. So all tasks are
+ 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.
@@ -96,7 +96,7 @@
-
Before building the Ant1 Compatibility layer, you need to build
+
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.
-The project file format is very similar to that of Ant 1. The root element of
-the project file must be a <project> element. It can
-take the following attributes:
+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:
@@ -20,7 +27,7 @@ take the following attributes:
name
The project name.
-
The base-name of the project file, with the extension removed.
+
The name of the project file, with the extension removed.
basedir
@@ -36,7 +43,7 @@ take the following attributes:
version
-
The project file version that the project is written for.
+
The project file format version that the project is written for.
Project references allow the project to import, or reference, other projects.
A <projectref> element takes the following attributes:
@@ -74,7 +81,7 @@ A <projectref> element takes the following attributes:
The targets of a referenced project can be used in the depends list
-of a target in the referencing project, using the following syntax:
+of a target in the referencing project, using the syntax
project-name->target-name. Here is a simple example:
-
+
Library imports allow the project to import the tasks and data-types from an
antlib. An <import> element takes the following attributes:
@@ -141,11 +148,11 @@ the my-tasks antlib.
-
+
-
Implicit tasks are run before any of the project's targets are run. Any task
-can be used, including <property> and data-type instances.
-Implicit tasks can be used to initialise the project. For example:
+
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:
-
+
Targets have a similar format to targets in Ant 1.x, though some of the
behaviour is different. A <target> element takes the
diff --git a/proposal/myrmidon/src/xdocs/classloader.xml b/proposal/myrmidon/src/xdocs/classloader.xml
index 1d81cdd39..0a08ff87c 100644
--- a/proposal/myrmidon/src/xdocs/classloader.xml
+++ b/proposal/myrmidon/src/xdocs/classloader.xml
@@ -2,7 +2,7 @@
- On ClassLoaders in Ant2
+ On ClassLoaders in Ant 2Peter Donald
@@ -10,9 +10,9 @@
-
In many ways Ant2 needs to follow rules similar to a number of
+
In many ways Ant 2 needs to follow rules similar to a number of
different application servers with respect to ClassLoader management.
- Ant2 will create a number of different ClassLoaders that have access
+ 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
@@ -26,7 +26,7 @@
variables defined by said classes) in a parent ClassLoader are shared with
the child ClassLoaders.
-
Using kooky ascii art, the specific ClassLoader structure for Ant2 is as
+
Using kooky ascii art, the specific ClassLoader structure for Ant 2 is as
follows:
@@ -59,7 +59,7 @@
The
Common ClassLoader contains the classes and resources
- that are made visible to both the Container and to all the ant type librarys. This
+ 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;
@@ -85,7 +85,7 @@
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 ant2 versions.
+ notice between between different Ant 2 versions.
@@ -101,7 +101,7 @@
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 librarys as they implement
+ 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
@@ -111,7 +111,7 @@
The
Shared ClassLoader contains all the classes and resources
- that are shared across all of the ant librarys (unless they are als needed by the
+ 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
diff --git a/proposal/myrmidon/src/xdocs/configuring.xml b/proposal/myrmidon/src/xdocs/configuring.xml
index 6b8dfcc16..fe98cf7ab 100644
--- a/proposal/myrmidon/src/xdocs/configuring.xml
+++ b/proposal/myrmidon/src/xdocs/configuring.xml
@@ -2,7 +2,7 @@
- On Task Configuring in Ant2
+ On Task Configuring in Ant 2Peter Donald
diff --git a/proposal/myrmidon/src/xdocs/differences.xml b/proposal/myrmidon/src/xdocs/differences.xml
index 25c34b1b4..333677e23 100644
--- a/proposal/myrmidon/src/xdocs/differences.xml
+++ b/proposal/myrmidon/src/xdocs/differences.xml
@@ -1,7 +1,7 @@
Adam Murdoch
- Differences to Ant1
+ Differences to Ant 1
diff --git a/proposal/myrmidon/src/xdocs/getinvolved.xml b/proposal/myrmidon/src/xdocs/getinvolved.xml
index a4f4c6705..39b0dbf69 100644
--- a/proposal/myrmidon/src/xdocs/getinvolved.xml
+++ b/proposal/myrmidon/src/xdocs/getinvolved.xml
@@ -8,10 +8,11 @@
-
There are plenty of things you can do to help out with Myrmidon. The Todo
- list below 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.
+
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:
Myrmidon is a proposal for Ant 2. Ant2 is the next evolution of the
- Ant build tool aimed at removing many of the limitations of the Ant1.x
+
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;
@@ -40,7 +40,7 @@
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 ant1.x but prohibitively difficult).
+ 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.
@@ -55,7 +55,7 @@
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.
+ and install tools based on the Myrmidon base.
diff --git a/proposal/myrmidon/src/xdocs/librarys.xml b/proposal/myrmidon/src/xdocs/librarys.xml
index 6883953dc..795c73eaf 100644
--- a/proposal/myrmidon/src/xdocs/librarys.xml
+++ b/proposal/myrmidon/src/xdocs/librarys.xml
@@ -2,7 +2,7 @@
- On Librarys in Ant2
+ On Libraries in Ant 2Peter Donald
@@ -10,13 +10,13 @@
-
Long ago there was identified the need for librarys that contain
+
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 Ant2. The librarys (also referred to as
+ defined and used in Ant 2. The libraries (also referred to as
deployments) will be termed antlibs.
-
Ant librarys can be packaged and signed into a ANt Type Library
+
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
@@ -33,7 +33,7 @@
be referenced in the build file (an example being DTDs).
-
The library may also need access to other librarys or resources
+
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
@@ -79,7 +79,7 @@
ant library thus needs a mechanism via which to declare dependencies on
external libraries.
-
Ant2 uses the "Optional Package" mechanism. Prior to JDK1.3, an "Optional
+
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
@@ -139,7 +139,7 @@ trax-Implementation-Version: 2.1.0
trax-Implementation-Vendor: Apache Software Foundation
-
To make other jars available to Ant librarys as "Optional Packages"
+
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;
Integrate with the XDocs proposal that generates XML documentation for
- tasks. Rework that proposal so that it knows about the myrmidon specific
+ 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.
@@ -281,25 +281,25 @@ public class MyrmidonSecurityManager
-
The Ant1 Compatibility layer is still in early stages of development.
+
The Ant 1 Compatibility layer is still in early stages of development.
Get a version of <antcall> working.
- Provide hooks between Ant1 references and Myrmidon properties.
- May use converters for adapting Ant2 objects (like Ant2
+ Provide hooks between Ant 1 references and Myrmidon properties.
+ May use converters for adapting Ant 2 objects (like Ant 2
<path> or <fileset>)
- as Ant1 types.
+ as Ant 1 types.
Missing tests:
-
Make sure properties are shared between Ant1 and Myrmidon tasks.
+
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
- Ant1 Project, to minimise the amount of code duplication in
+ Ant 1 Project, to minimise the amount of code duplication in
Ant1CompatProject.
@@ -524,9 +524,6 @@ public class MyrmidonSecurityManager
<socket>
conditions to an antlib. Need to resolve how these will be passed a logger.
-
Allow the
- <if> task to take any condition implementation.
-
Add an else block to the
<if> task.
@@ -551,6 +548,9 @@ public class MyrmidonSecurityManager
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.
First, you will need to fetch the Myrmidon source from CVS. The source
-can be source in the proposal/myrmidon directory of the
+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.
@@ -97,10 +97,10 @@ prompt> java -jar ant-home/bin/myrmidon-launcher.jar optionsWhen 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 given on
-the command-line, or the default target if none is given. For example, the
-following executes the targets clean and build from
-the project file my-project.xml:
+-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: