xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [Proposal] Creation of the Apache XML "Ant" Project
Date Mon, 15 Nov 1999 14:28:00 GMT
Hi people,

there are lots of discussions going on in both jakarta.apache,
xml.apache and java.apache on what is the best way to build things. For
pure java projects, gnu tools seem kind of "untuned". For this reason
the Ant tool was developed internally at Sun to create their Tomcat

As you probably know, Ant was donated to the ASF together with the other
jakarta code and it's currently hosted in the jakarta-tools CVS module
but many people showed much interest for upgrading the tool and make it
more complete.

So, it was proposed to the Jakarta PMC to make a full blown project with
its own CVS, mail list, docs and such. A number of TODO items is present
in the current CVS module.

The Jakarta PMC agreed to move this up one level, but many (me first)
think that this tool is general enough to belong to this project rather
than a servlet-related one. Expecially because close XML and XSL
integration are planned. (XML is used for the build file, XSL for code
generation FOP-style)

The proposal is the following:

1) create a new subproject hosted in the xml.apache.org web site called
2) create a new CVS module named "xml-ant"
3) create a new mail list named "ant-dev@xml.apache.org"
4) move the existing code from jakarta-tools to xml-ant
5) move the package names from "org.apache.tools.ant" to
6) add XML group to James Davidson (original author of Ant) to allow
write access to him which will be the maintainer of the project.

Possible impact of this proposal:

1) no impact on C/C++/Perl projects: we do _not_ want to reinvent the
wheel rewriting gmake or autoconf/automake in Java. Ant will remain Java
focused for design.

2) great impact on pure Java projects: Ant aims at completely replacing
other possible build tools for java/XML specific needs. Special care
will be given to java-related tasks like (javac, javadoc, rmic, javah,
jar) as well as platform indipendence and tool replacement (javadoc 1.1
vs. javadoc 1.2, javac vs. jikes, etc...)

3) impact on mixed native/java projects: Ant aims to integrate
seemlessly with more widely used build tools such as Gmake and libtool.
It may be considered as a java specific build-engine that can be used as
a subprocess in a more general build process. It is a major Ant's goal
to allow mixed projects such as Jakarta Tomcat and Apache JServ to use
Ant to generate/handle the java-specific side of things while _not_
requiring Ant to build the native part (which is much better handled by
existing tools).


1) pure java (native commands are issued thru Runtime.exec() but
complete java replacement of the tools used is preferred when possible)
2) platform independence (JVM version, OS, tools availability should be
handled directly by the tools hiding problems to the user)
3) tiny footprint (Ant is currently a 37Kb jar file. Small footprint is
necessary since projects might choose to distribute a binary version of
Ant to their users/devs directly)
4) XML build file (XML syntax is used to simplify learning, updating and
5) XML output file (XML _may_ also be used as output format, to allow,
for example, XSLT stylesheets to filter/publish the building
6) big simplicity/power ratio (Ant should hide major common problems in
java building)
7) complete modularity (it should be possible and easy to add new tasks
to the build process as java code. A small API of common methods should
be provided)
8) no code inside build files (this is to reduce management costs and
easy migration in between developers)
9) should integreate seemlessly with other Apache projects such as
Xerces, Xalan and Cocoon/StyleBook as well as most common tools such as
CVS, Javac, JavaDoc, Jar, etc..

Possible future improvements:

1) crond-like operation (automatic nightly builds)
2) mail integration (if something is wrong the log is mailed directly to
the administrator/code owner/dev mail list)
3) servlet/GUI interface?

Things still to evaluate:

1) creation of a general test harness tool for regression tests. Should
this be included in Ant or in a separate project (like Jakarta Moo

Please, people, place your vote.

[Note: only active developers are allowed to make pending votes, but
since this is an open project, we would like to hear any comment before
making a decision because the more comments the better. :)]

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche

View raw message