Stefano Mazzocchi wrote: > [EMAIL PROTECTED] wrote: > > > > Here's what I've heard so far in terms of requirements for the build: > > > > a) We should stick with pervasive build tools, so people can edit/debug > > more easily, and so that we can rely on the tools being present in the > > target OS. > > b) If we use a non-make tool it better be in the download.
Well Ant can already be downloaded from the Jakarta site. Even with Jakarta to build it we need to download jakarta-tools. That's not been a problem so far and I don't see any reason why it should be???. You don't want to increase the size of the bundles. People using modem lines will have a problem with the utility being bundled especially if the size of it is significant. By keeping it separate they need to download it only when the utility is upgraded. > > c) We shouldn't maintain two parallel build systems, one for UNIX and one > > for Windows. Build using Java ;).. > > Totally agreed. > > > Here are my specific beefs with the current system: > > > > 1) It uses GNU make. This means that someone has to install GNU make on > > some Unices. > > On Windows, it means someone has to install either Cygwin (free but > > multimegabyte) > > MKS Toolkit (costs $$$), or have a make from something like VC++ (also costs > > $$$) > > I don't believe that we can rely on the target machine having the right make > > based tool. > > The current build system relies on Cygwin on Windows and some make on UNIX. > > Even this > > requires too much setup of environment variables for things like classpaths, > > and cygwin's > > MAKE_MODE, etc. > > > > In order to build the Java version of Xerces (which is what we're discussing > > here), you > > will have to have Java. If we had a Java based tool, we could eliminate > > all reliance on an > > extra build tool. > > Agreed also on the analysis. > > > AFAIK, there are only two choices: ANT and jmk > > (http://www.ccs.neu.edu/home/ramsdell/make/edu/neu/ccs/jmk/) > > > The problem with ANT is that it is a non-pervasive tool. It uses a > > configuration file syntax > > the most people have never seen. Most people on this list have something to do with xml and it shouldn't be tough for most of them to understand it. > > People will complain about this, and it > > will make it harder > > for people to help out with build related stuff. > > I don't think so: Ant sintax is really simple and straightforward. > Tomcat build.xml is complex because tomcat is complex. Most java > applications require a couple of lines of build.xml like in my previous > message I outlined. Totally agree with Stefano. > > > Also, the current build > > does a few things that > > ANT doesn't have direct support for (except via Exec, which I'm not sure > > will do > > the job): running stylebook to generate the documentation, and running > > javadoc to build > > the API docs. It looks like it would be easy to extend ANT to do these two > > tasks correctly, > > if that turns out to be necessary. The source is out there.. ;).. Modify and use it and submit it as a patch to the jakarta list. If it is reasonable functionality I am sure it will be included in Ant. > > I'm coding this right now to get rid of makefiles in Cocoon. > > > I would be curious to know what the > > Jakarta folks' experience > > with ANT has been, regarding the approachability of the configuration files. > > They had no problem at all. This is the power of Ant: is java specific. > If you change class names, package names, and blah blah, you don't have > to change anything in your build script. Ant will take care of that. > > Also, Ant will not recompile what you have already compiled. It may use > jikes instead of javac and generate your docs using stylebook or your > Java code using XML/XSL (like FOP is doing right now), simply depending > on the task element you want. > > And if something is missing, plug in your own task and you're done. > > I think such a project is really cool and it should deserve it's own > project, maybe here in between the XML stuff. > > > jmk is only a little better, because it uses a syntax that looks close to > > Makefiles, but isn't > > real Makefile syntax either. People (including me) will complain about > > this. Moreover, jmk > > is using the LGPL license, which might be a problem for us. > > I don't like jmk either. > > > The ideal solution would be a Java implementation of Makefile syntax, but > > I'm not aware of > > such a tool. > > Why? because people know make syntax more? Granted, but how much does it > take to learn a DTD from examples? How long did it take to write your > first HTML page looking at someone else's one? > > C'mon, we are the Apache XML project after all :) Good one Stefano. +1 on using Ant with the java parser. - Rajiv > > -- > Stefano Mazzocchi One must still have chaos in oneself to be > able to give birth to a dancing star. > <[EMAIL PROTECTED]> Friedrich Nietzsche > > -- UNIX _is_ user friendly, he's just very picky about who his friends are.
