ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Dawson" <>
Subject Ant 1.9 & Task Packaging
Date Mon, 21 Jan 2002 21:37:31 GMT
I apologize in advance if this is a duplicate send or the topic has
otherwise been discussed in the last week. I recently switched email
accounts and hadn't remembered to re-subscribe under the new address. states that "We have
already decided that we are going to package Ant tasks in separate jars and
have some sort of descriptor that to describe the contents of the jar."

The task item is to determine how to break up tasks, e.g. related tasks,
groups to use together, etc. I would suspect that one way to clearly break
them up would be based on package - currently we have a few packages,
"taskdefs", for the - supposedly - core stuff, and taskdefs.compilers,
taskdefs.condition, taskdefs.rmic, and then a catchall, taskdefs.optional.*
where everything else is bunched. This is a bit confusing as some tasks
haven't been migrated to a hierarchy, etc.

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.

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)
	(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)

All these would go inside ant.jar.  Anything optional would go in a
subpackage of and created inside their own
jar file - e.g.

or be migrated to the respected vendor's product and placed in that vendor's
jar file.  Anything inside of core and included in the build would have to
pass a strict "can this run without ANY 3rd party jars?" Everything else
would be a separate jar, and need to explicitly included in the build file
with <tasklib> (or whatever its called).

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.

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.

IMHO, this topic is one of the most critical things holding Ant back right
now. If you look at the way BEA has extended Ant, they include Ant  1.3 with
their product so that they can add automatically a few custom tasks (e.g.
their web services generator 'wsgen'). Of course this breaks when I try to
use Ant 1.4.1 with their task.  BEA should be able to provide a
"weblogic.jar" that could just be referenced in a build file, and used with
whatever recent version of Ant you've downloaded.

So, this is my proposal. I'm not sure it helps with the Ant 1.9 item since t
hat's more slated to changing the existing Ant 1.x tree, but I figured it
would be worth throwing out there. Personally, I don't think we're going to
make a ton of progress on Ant2 without a clean break, but I'm interested to
see what others think.


Do You Yahoo!?
Get your free address at

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

View raw message