ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ru...@us.ibm.com
Subject Re: Release plan
Date Tue, 11 Apr 2000 13:19:00 GMT


Now that the Tomcat 3.1 activities are wrapping up, it is time to begin
planning the next release of Ant.  By popular demand, at this point I think
that we should decouple Ant from the Tomcat release cycle.  So lets begin
by referring to previous releases as 0.3.0 and 0.3.1 (note the initial
"0."), and begin planning release 1.0.

For starters, I would like to say that I do *not* expect 1.0 to be 100%
backwards compatible.  Items of dubious value and deprecated features may
be removed.  I'm thinking about things like the automatic copying of any
files that Javac sees that don't end in ".java" to the destination
directory, and alternate spellings for classname parameters.  This being
said, I do not expect anybody using an existing version of ant to have to
spend more than a few minutes doing an upgrade.

High items on my list (many of which already have patches submitted)

- The ability to use any JAXP compliant parser

- Separating the "initializers" (items which are to be directly nested in
the project) from the "tasks" (elements which are to be nested in
"targets")

- Restructuring of the "core" tasks so that they are more useful as
building blocks (example: the exec task)

- Organizing the "non-core" components in such a way that users can more
easily pick and chose the subset that they want.  Does everybody need RMIC?
This should hopefully open the door for expanding the universe of taskdefs.
Note: I have no personal preference as to whether taskdefs which integrate
Ant with another product are shipped with Ant or with the other product.
Nor do I see it as a requirement that the item being integrated be open
source.  All that is required is that the taskdef itself be shipped under
the Apache license if it is to be included in Ant, and that it be optional
for those that don't require it.

- Enabling the construction of building blocks in XML for build processes.
The jakarta-taglibs project is an example of a family of components with a
fairly uniform build process for each.  It would be nice if this uniform
build process were defined in one place, and the individual build.xml's
could contain only the unique information about the subsystem.

- Converting the .antrc / antrc.bat / defaults.properties into XML.  I view
these as special cases for the building blocks described above.

Suggestions?  Volunteers?

- Sam Ruby



Mime
View raw message