xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <twle...@sauria.com>
Subject Re: [Proposal] Creation of the Apache XML "Ant" Project
Date Mon, 15 Nov 1999 18:41:40 GMT
There are systems where make is not present.  In particular,
On Windows and the Macintosh, you cannot count on having
a make tool present.  Make is not a cross platform build tool.
We've had lots of Windows users complain that they have to
download "weird make tools" in order to build a Java program.

I'd like to propose that we do an experiment:

Let's get someone (Stefano, maybe) to do the ANT build file
for xerces-j, and then post it here so we can take a look and
compare it to the makefile.

If we like it, we do another experiment by using it as the build
system for unstable builds for a few months.  Based on that
experience, we decide whether there really is a barrier to entry
problem based on ANT syntax.  If there isn't, we go ahead.
If there is, we beat someone into writing make in Java ;-).

----- Original Message -----
From: Dirk-Willem van Gulik <dirkx@webweaving.org>
To: Apache XML <general@xml.apache.org>
Cc: James Davidson <james.davidson@eng.sun.com>
Sent: Monday, November 15, 1999 8:01 AM
Subject: Re: [Proposal] Creation of the Apache XML "Ant" Project

> 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. :)]
> >
> >

View raw message