ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Ant 1.9 & Task Packaging
Date Tue, 22 Jan 2002 09:00:12 GMT
On Tue, 22 Jan 2002 08:37, Tim Dawson wrote:
> I think we should consider Ant2 to be a brand new project, similar to what
> Xerces, Xalan, and Cocoon have done. Trying to migrate the Ant1.x code
> base, IMHO, has really held Ant2 back. We've been talking about it for over
> a year now, it seems.

We have been at it for over a year. I think the first prototype was finished 
september 2000. Ant2 has never been a migration of Ant1.x code - in fact we 
have had 6 different ants rewritten from scratch. Unfortunately the best 
first-cut was largely ignored by ant-dev because it was a non-committer who 
submitted it.

Ant2 has not happened because the only reason some people want to contribute 
to it is to see their names as authors and they want to "own" ant core and 
control its evolution to one degree or another. I was told by at least one 
other "committer" not to work on Ant2 because it was selfish ... ;)

Until recently I had never thought Ant2 would actually occur because I was 
under the impression that some other committers would block anything I did 
and no one else seemed to be willing to do the work.

Then Stefan said he would no try to block anything unless it really sucked - 
however he wouldn't support or work on anything until it was ready to go. 
kool I thought and started working on ant2 again ;)

Feel free to dig into proposal/myrmidon if you want a scratchpad to work in. 
No backwards compatability or anything like that is needed in there and it is 
slowly aquiring the ant1.x tasks with which to test ideas.

> If we did that, then I'd recommend creating new packages (and thus task
> groupings) inside the core based on type of function, but outside the core
> based on NOT on function type (as taskdefs.optional.ejb does, grouping
> WebLogic and IPlanet tasks together) but more following the package its
> defined to work with (as taskdefs.optional.clearcase,
> taskdefs.optional.perforce, taskdefs.optional.starteam do). For example:
> 	(main engine, interfaces, abstract superclasses)
> (not taskdefs)
> 	(empty?)
> 	(typedef, tstamp, property, wait, exec, tasklib, etc)
> 	(Move, Copy, Mkdir, Patch, etc)
> 	(javac, etc.)
> 	(Filter, Style, etc.)
> 	(Get, Mail, etc)
> 	(Tar, War, Jar, Zip, etc)

Thats one way of doing it. Another that I am currently doing is


where <group> is one of the ant-dev maintained sets of tasks/types like 
text/file/net/whatever. In this case there would be no difference between 
core and optional packages at all. The reason is that even "core" ant tasks 
have external dependencies (ie zip, tar and bzip tasks all currently use 
external utility classes). Thus core/optional it no longer a really useful 

Each of these separate packages would be put into separate jars and could 
theoretically be loaded independently of each other.

> This would allow the optional jars to do their OWN checking to make sure
> dependencies were in place. I know it drives me nuts to have to write my
> own checks and <fail> tasks to ensure that a library is present before a
> call to an optional library so our junior developers don't get stuck with a
> "classnotfound" exception they can't figure out.

Another way to do this (and the standard way for java applications) is via 
the JDK1.3 "Optional Packages" Specification. It is used by applets, 
servlets, ejbs, etc and is starting to get support inside jakarta projects.

SO you read a manifest for a task library and if it declares dependencies on 
external libraries and these libraries are not present then it will cause an 
exception to be throw with a semi-useful message.

> Further, if we're really moving to a container architecture with Ant2, then
> we should define a spec for the build file, execution engine, and task
> extensions API through a JSR and have a separate jakarta project for the
> optional task libraries, similar to the "taglibs" project that provides
> libraries for extending JSP. That project would build many jar files, which
> could be included in the project via build file reference & descriptor as
> mentioned above.


I have campaigned for this many a time but everytime there is a committer 
that will veto it ... 



| Every rule has an exception,   |
| except the rule of exceptions. |

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

View raw message