Hello, I like very much your ideas Jesse and my experience is similar to yours. I shy away from complex ant projects (several build files importing each other ..., lots of antcall, ...) because I find them hard to master. I am not sure of understanding myself all the rules concerning scopes of properties, targets, references, across <import/>, <ant/>, <antcall/> ... Uhhm, perhaps we should add a page "ant syntax, scopes ..." in the manual.
I do not have problems with writing build files in XML format, but I have a problem with our syntax and I am always afraid to break something, actually more than with a compiled language. What about, if the members of ant-contrib were to agree to this, merge ant and ant-contrib to have the <if/> ... at home and go out of this business of creating targets to set properties ? I worked previously for a large software house building litterally 1000's of projects using ant. Most of the build files of the individual projects were generated, either using velocity and templates, or by a java command line program using a macro language as its input. Talking about a scripting language to "marry" with ant, I am surprised no one mentioned groovy. Regards, Antoine Jesse Glick wrote: > I was wondering if anyone would bring it up... > > +1 (is >1 allowed?) for including a scripting language implementation > in the standard Ant distribution, so that we can rely on it being > there. In fact I would suggest making Ant 2.0 assume a script as its > input, and have a compatibility mode for old XML scripts. > > -1 (or <-1 if allowed) on writing our own DSL. > > -0 on rewriting existing tasks in the Ant distribution in another > language. Would just confuse the code base. Focus on users of Ant, not > developers of Ant. Of course users should be able to write tasks in a > scripting language if they prefer. Ideally this would be the same > thing as just writing a plain old library file. > > -0.5 on Lisp or Scheme. Don't get me wrong, I probably would have been > miserable as a teenager were it not for CLtLR2. But the last thing we > want to do is make life harder for a random Java developer to build > his or her program. Ant-in-Lisp would be far far better than the > current XML mess, to be sure, but I think a relatively mainstream > language like Rhino would be a lot more accessible. Lots of Java > developers already know JavaScript from web development anyway. > BeanShell is also an easy step for Java developers. JRuby and Jython > are probably a bit more accessible than Lisp but less than JavaScript > and BeanShell. > > My personal experience with Ant has always been that the tasks are > great, and the control flow is maddening. To write an interesting > script, I generally spend most of the time wrestling with if and > unless attributes, artificial targets set up to define properties at > the right times, weird <pathconvert> hacks, refid->string conversions, > selectors, and other gobbledygook. Generally all of this could be > replaced with a few lines of elementary JavaScript or any other > general-purpose language with sensible bindings and library functions. > .... > I don't buy the argument that Ant is currently "declarative". It's > nothing of the sort in my experience. When you think about what a > build script does, it runs a sequence of actions, possibly with some > control flow, and uses variables which are defined through a > potentially complex series of interactions with the environment. > That's a program, not a declaration. Make tried to impose a Prolog-y > model onto the problem, with the result that only Prolog programmers > could understand makefiles, and recursive make never really followed > the model anyway. Ant is easier to understand because it works more > like a sequential program, and file up-to-date handling is bundled > into tasks. So why is it written in a cumbersome XML dialect which is > incapable of expressing elementary computations? > > -J. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
