ant-dev mailing list archives

I have a few ideas for ant 2.0, and would like to know what everyone
thinks. I have a protoype that does most of this - if there's enough
interest I'll finish it up and submit it.
The biggest change is the ability to import one project from another. This
gives you access to all of the properties and targets defined in that
project, which can be accessed by using the colon as a namespace operator.
For example, if your project depended on the xerces jar, and you wanted to
make sure that jar was up to date before compiling against it, you could do
this:
<project name="foo">
<import name="xerces"/>
<target name="compile" depends="xerces:jar">
<javac classpath="${xerces:dist.jar}">
...
</javac>
</target>
</project>
Upon reading the import statement on line 2, Ant would search the "project
path" looking for a file called "xerces.ant" and parse it. The project path
would include the current directory, the install directory, and any other
directories/jars that the user wishes to define via a properties file or
environment variable. This lets us reference 3rd party
binaries/tools/source without having to know specifically where they're
installed. It also lets us break up large ant files into separate projects
without xml tricks or "recursive make" issues. And if the project can't be
found locally we can download it from CJAN...
Another change is to not instantiate task objects until right before
they're executed. This allows us to define the task in the same script
where we use it:
<project name="foo">
<target name="compile">
<taskdef name="ejbc" classname="...."/>
<ejbc>
...
</ejbc>
</target>
</project>
Now, with the two changes above, we can create projects that just define
tasks, whose sole purpose is to be imported from other projects. For
example, the antfile for a set of weblogic tasks might look like:
<project name="wl-tasks" export="init">
<target name="init">
<taskdef classpath="...">
<task name="ejbc" classname="..."/>
<task name="ddcreator" classname="..."/>
...
</taskdef>
</target>
</project>
Now as long as this antfile is somewhere on my project path, I can load
these tasks by just importing the wl-tasks project (which automatically
runs the "init" target above, thanks to the "export" attribute):
<project name="foo">
<import name="wl-tasks"/>
<target name="compile">
<ddcreator .../>
<ejbc .../>
</target>
</project>
And finally, I've changed the "baseDir" attribute on project so that it can
be either a directory or a jar (any URL, actually). This means that you can
execute an antfile stored inside a jar, and have it load tasks stored in
that jar. This gives us the "drop a jar in the right directory" mechanism
for installing tasks.
So all of this basically gives us an easy way to install new tasks on a
system, and it does so without any new syntax, since everything is an ant
file. It also gives us a uniform way of describing dependencies between
projects, and paves the way for something like CJAN. IMHO, of course.
thoughts?
Matt Foemmel
ThoughtWorks, Inc.