xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: [Proposal] Creation of the Apache XML "Ant" Project
Date Mon, 15 Nov 1999 16:01:48 GMT

Now correct me if I am wrong; but is this not a bit over the top? 

We have very simple requirements and dependencies in our java builds; i.e
because it is all so platform independent there is little more than just
a few targets. This breaks down to being able to do:

1	convert 	*.java -> *.class

		compiler of some sort (javac)
			occasionally with a fancy classpath ?
			but mostly a javac *.java in a directory just
			does the trick.

2	collate *.class -> *.jar
		jar of some sort.

3	cleaning
		rm et.al.

4.	perhaps
		convert		to java doc where needed

5.	installing
		perhaps cp/copying a couple of *.jar and *.html
		files around a little.

Unlike C and C++ we have few -D define like construct's, etc, etc as java
is platform independent enough. So why not stick to simple make ? We could
get away with just an exported MAKE, RM, CP, JAVAC, JAR and CLASSPATH
variable. If you keep all relative live stays simple. No ../includes
needed either :-).

Seriously: I am really a little lost here. There is a weath of experience
with using small little things, such as 'make', 'rm', 'cp'; which all do a
simple thing well, to drive more complex build's, tests and install's.

I am not so sure this reinvent-ed wheel (in java this time) is going
to be that much rounder and better. 

All I see is buzzword compliancy and general coolness sofar.

Dw. 

-- 
Q: What is the better 'wheel': triangle, square or a hexagon ?
           ! noitulover rep spmub fo rebmun tsael; elgnairt :A

> Goals:
 
> 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
> validation)
> 5) XML output file (XML _may_ also be used as output format, to allow,
> for example, XSLT stylesheets to filter/publish the building
> information)
> 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
> today?)
> 
> 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. :)]
> 
> 


Mime
View raw message