As an end-user, I'm not sold on the bundling of Ant either. My logic is as follows:
The first thing I'll see after having checked out a project are two files that will potentially build the project - build.bat and build.xml. I'm always reluctant to run a build.bat script without seeing what it does, in case it screws up my environment vars or worse. But because it's supplied, I assume it's there for a reason and that ant/build.xml won't function properly without it. So I generally tread carefully - look at the readme, look at build.bat etc before taking the plunge. This always feels a bit clunky. If only build.xml is present, I type ant and hit enter :) Of course, if things blow up at this point I need to figure out why (which is where I then look at the readme etc), but I'm far more comfortable with this approach. Note that in the past I've always been a bit uncomfortable with webwork having two approaches to building. Sometimes I'll build it with ant, sometimes with build.bat. And I always have that slight nagging feeling that perhaps I've built it the 'wrong' way, or that by taking the other approach would yield a different .jar file. OK, so maybe I'm just being paranoid, but when there is a single, definitive approach, it seems there's one less thing that can go wrong. All the other suggestions re code formatting, structure seem fine to me. Just my 2 cents. Chris "Bill Burton" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... <snip> > I just don't think proliferating copies of Ant is the solution. <snip> ------------------------------------------------------- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
