suggestion : Ant 1.8 full dist to include a 'scripting lang'

[Steve Loughran]

Stefan Bodewig wrote:

> On Tue, 12 Sep 2006, Matt Benson <gudnabrsam@...> wrote:
>
>> dare I say it, could be fun if we could find ways to
>> make a DSL that is Ant-focused.  ;)
>
> Ant is a DSL, isn't it?
>
> The easiest thing would be a re-implementation of Ant in Common Lisp,
> we'd get real macros and a time-tested "scripting" language for free.
> and we could get rid of XML:
>
> (project :name "Ant" :default "echo"
>   (target :name "echo"
>     (echo :message "Hello World")))
>
> Tasks would be functions or macros.
>

...And make is an AI rule proving system that backward chains from
desired artifacts to the creation sequence, then runs them.

I'm not sure we want to make the jump to being procedural though, not in
the core.

FWIW I think my work build has pretty much reached the limits of Ant's
scalability. The problems I have are not script releated, they are
-library management
-managing overrides of base build.xml files
-functional testing
-xreferencing generated artifacts

I'm not going to make the jump to maven, though I may try it in one
project. What I am plannign to do is move functional tesing into
smartfrog deployments itself (see
http://people.apache.org/~stevel/slides/distributed_testing_with_smartfrog_slides.pdf 
), with
some more extensions to the test components.

I'm also thinking about whether or not to move some of the build process
into smartfrog itself, first with the ability to create WAR and EAR
files during deployment. There's too many XML and JAR files in there
that need to know what your target system is going to be
(hostname, platform, data sources), By doing deploy-time artifact
construction you get to do custom artifacts and avoid operations
sticking the wrong EAR on the wrong host.

-steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Steve Loughran]

Kevin Jackson wrote:

>> >> (project :name "Ant" :default "echo"
>> >>   (target :name "echo"
>> >>     (echo :message "Hello World")))
>> >>
>> >> Tasks would be functions or macros.
>> >
>> > Anyone interested in a CLISP version of Ant?
>>
>> You'd be surprised how much less lines of code you'd need when
>> compared to the Java version, really.
>
> No really I wouldn't!  Java is a *very* verbose language, Lisp is
> probably one of the least verbose languages (apart from the ())
>
>>
>> I toyed with the idea when I first read Peter Seibel's "Practical
>> Common Lisp (online here[1], but it's well worth of buying) and even
>> managed to get something like the above snippet working, actually more
>> like
>>
>> (defparameter *project*
>>   (project :name "Ant" :default "echo"
>>     (target :name "echo"
>>       (echo :message "Hello World"))))
>> (run-targets *project*)
>>
>
> I think a problem would be that CLISP Ant would also have to take
> build files in two formats (build.xml & build.sexp) so as to be
> partially bwc - of course CLISP can compile to native code and
> therefore would (in some cases) be easier to install than Ant + JRE

My collegue julio added ant support to smartfrog a few months back, so
we can run any ant task during deployment. What you dont get is rollback
and liveness operations. Here's a bit of an an example:


sfConfig extends Ant {
   asynch true;
   echoTask extends echo {
     message "hellow world!";
   }

    echoAntTask extends echo {
       message "Ant version '${ant.version}', java version
'${ant.java.version}";
    }

   copyTask extends copy {
       todir "tmp";
       filtering "true";
       myFileSet extends fileset {
         dir ".";
         includes "*.xml";
       }
       myFilterSet extends filterset {
          myFiltersFile extends {
            AntElement "filtersfile";
            file "/filters.props";
          }
       }
   }
   echoMedTask extends echo {
     message "--------------------------------";
   }



   copyTask2 extends copy {
       todir "/juliotmp/kk";
       filtering "true";
       verbose "true";
       myFileSet extends fileset {
         dir "/";
         includes "*.txt";
       }


       globMapper extends globmapper {
         from "*";
         to "*.bak";
       }

   }

   copyTask3 extends copy {
       todir "/juliotmp/kk";
       filtering "true";
       verbose "true";
       myFileSet extends fileset {
         dir "/";
         includes "*.txt";
       }

       flattenmapper extends {AntElement "mapper"; type "flatten";}
   }
}

when you run this, the outer Ant runs everything and sets all the final
ant properties as attributes of the deployed task, so other smartfrog
stuff can work. Apparently getting <condition> to work caused problems,
as it is not enough to run every task. Here's the LGPL runner:

     private void executeNestedAntTasks() throws RemoteException,
SmartFrogException {
         Object attribute = null;
         Object value = null;
         Iterator a = this.sfAttributes();
         try {
             for (Iterator i = this.sfValues(); i.hasNext() &&
!exitAntNow;) {
                 attribute = a.next();
                 value = i.next();
                 if (value instanceof ComponentDescription) {
                     try {
                         if (((ComponentDescription)
value).sfContainsAttribute(ATTR_TASK_NAME)) {
                             Task task = antProject.getTask((String)
attribute, (ComponentDescription) value);
                             task.execute();
                         } else if (((ComponentDescription)
value).sfContainsAttribute(ATTR_ANT_ELEMENT)) {
                             Object element =
antProject.getElement((String) attribute, (ComponentDescription) value);
                         } else {
                             //System.out.println("@todo: something with
attribute: "+ attribute + " "+value+";");
                         }
                     } catch (Exception ex) {
                         Throwable thr = ex;
                         if (thr instanceof
java.lang.reflect.InvocationTargetException) {
                             thr = ex.getCause();
                         }
                         throw SmartFrogException.forward("Error
executing: " + attribute, thr);
                     }
                 }
             }
         } finally {
             //set the static properties after we finish
 
runtime.setStaticProperties(antProject.getProject().getProperties());
         }

     }

Everything is configured using reflection.



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Jesse Glick]

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.

The Ant scripts generated by NetBeans are also crippled by the lack of
scripting. For example, seemingly trivial problem: given a ${classpath}
which might be defined in some .properties files and which might include
files from anywhere on disk, copy the JARs into a build dest dir. Now
<copy> can take a fileset, but you have a path, not a fileset, and there
is no root. If the number of classpath elements were fixed, you could
write several <copy> tasks in sequence, but there can be any number of
elements. Solution? Either (1) regenerate a build script using XSLT from
some other definition file (eek!); (2) distribute a special task JAR to
copy a list of files specified by path, and make sure that this JAR gets
somehow referred to from every project's build script. An awful mess.
And in JS? All this could be replaced with something like

for (jar in classpath.split(':;')) {copy({file: jar, todir: destdir})}

which anyone can read and understand at once. Furthermore it is trivial
to see how to make a little modification to the above:

for (e in classpath.split(':;')) {
   if (e.endsWith('.jar')) copy({file: e, todir: destdir})
}

If we had scripting bindings, we could get rid of or deprecate a lot of
weird task options, conditions, selectors, and so on. General rule of
thumb: if your XML grammar includes elements named <and>, <or>, and
<not>, you are doing something wrong. :-) Who needs to pore over the
reference documentation for a date selector when you can just write e.g.

newfiles = scan(basedir, '**/*.java', function(f) {
   return f.lastModified() > ref.lastModified()
})

If targets were replaced by functions, and <import> by load(...), you
could compose scripts as normal library files, without having to sweat
over idiosyncratic inheritance and naming rules in the Ant manual, not
to mention the confusing ways that properties and references are passed
to subscripts, which does not match the semantics of any real language.
Things that look like function calls would really be function calls
(with parameters), lexically scoped and global identifiers would be what
they appear, variables could vary.

You could just say that by default all (top-level) functions in a script
are targets; if you wanted to use some library functions and expose only
certain targets, just use e.g.

function build() {
   compile()
   jar()
}
function compile() {
   javac({srcdir: 'src', destdir: 'build/classes'})
}
function jar() {
   jar({basedir: 'build/classes', jarfile: 'myapp.jar'})
}
function clean() {
   delete({dir: 'build'})
}
TARGETS = [build, clean] /* build is first, so default */

If you really feel the need for infrastructure to run a given target
only once (which I do not think should be the default behavior), this
should be easy enough in JS:

function build() {
   once(compile)
   once(jar)
}
function compile() {...}
function jar() {
   once(compile)
   // ...
}

where once is defined to be something like this:

function once() {
   var targ = shift(arguments)
   if (!this.ran[targ]++) {
     apply(targ, arguments)
   }
}

Managing properties would also be far easier if you could be explicit
about their lifecycle and precedence. E.g. if run with ant -Dx=y and
build.properties containing "foo=value\nx=y2\nlocation.y=there":

print(x) // prints 'y'
var p = properties('build.properties') // load defs into map
print(p.foo) // prints 'value'
print(p.x) // prints 'y2'
add_defs(/* to */ this, /* from */ p, /* override? */ false)
print(foo) // now prints 'value'
print(x) // still prints 'y'
function sometarget(location) {...}
sometarget(this['location.' + x]) // called with 'there'
load('other.js') // defines function othertarget(defs) {...}
othertarget(p) // pass it what you loaded
othertarget(this) // pass it my own properties

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.

--
jesse.glick@...  x22801  netbeans.org  ant.apache.org
       http://google.com/search?q=e%5E%28pi*i%29%2B1


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Dominique Devienne-2]

On 9/15/06, Jesse Glick <jesse.glick@...> wrote:
> My personal experience with Ant has always been that the tasks are
> great, and the control flow is maddening. [...]
>
> I don't buy the argument that Ant is currently "declarative". It's
> nothing of the sort in my experience. [...]

Whao, it's good you got that off your chest Jesse ;-)

Great post! I don't agree on all your points, but my experience is not
far from your own. I too would like to have an official and easy to
use scripting language always available in Ant (and ECMAScript is a
good condidate), but as a way to extend the default Ant behavior or do
a one off thing for a given build, not to replace the current Ant.

What you describe (Ant in JavaScript, or a build tool as a script
language program) as already been done in Ruby, or Python (A-A-P) and
probably lots others. It's a radical change from the current Ant, and
one that, despite the scripty nature of current Ant builds, would only
lead to even more scripty and spaghetti build "programs". I could be
wrong of course.

I have no doubt BTW that you could write a JavaScript-based
Ant-equivalent that leverages the current Ant tasks. Maybe you should
even starts such a project, and do changes in the core where necessary
to support this project, but Ant should go on in its current XML-based
form IMHO, however flowed many people find it.

--DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Alexey Solofnenko]

There is also another possibility (the one that I am using) - write scripts
that generate ANT scripts and run them.  It is slower, but it is more
lightweight in a sense that it is completely separate from ANT, so it does
not depend on ANT code. That script could be in any language, but a language
with helpful syntactic sugar would be preferred.

- Alexey.

On 9/15/06, Dominique Devienne <ddevienne@...> wrote:

>
> On 9/15/06, Jesse Glick <jesse.glick@...> wrote:
> > My personal experience with Ant has always been that the tasks are
> > great, and the control flow is maddening. [...]
> >
> > I don't buy the argument that Ant is currently "declarative". It's
> > nothing of the sort in my experience. [...]
>
> Whao, it's good you got that off your chest Jesse ;-)
>
> Great post! I don't agree on all your points, but my experience is not
> far from your own. I too would like to have an official and easy to
> use scripting language always available in Ant (and ECMAScript is a
> good condidate), but as a way to extend the default Ant behavior or do
> a one off thing for a given build, not to replace the current Ant.
>
> What you describe (Ant in JavaScript, or a build tool as a script
> language program) as already been done in Ruby, or Python (A-A-P) and
> probably lots others. It's a radical change from the current Ant, and
> one that, despite the scripty nature of current Ant builds, would only
> lead to even more scripty and spaghetti build "programs". I could be
> wrong of course.
>
> I have no doubt BTW that you could write a JavaScript-based
> Ant-equivalent that leverages the current Ant tasks. Maybe you should
> even starts such a project, and do changes in the core where necessary
> to support this project, but Ant should go on in its current XML-based
> form IMHO, however flowed many people find it.
>
> --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Alexey N. Solofnenko trelony at gmail.com
home: http://trelony.cjb.net/
Pleasant Hill, CA (GMT-8 hours usually)

[foamdino]

On 9/16/06, Jesse Glick <jesse.glick@...> wrote:
> I was wondering if anyone would bring it up...
>

Well it took a prod of actually meeting the main users - and
discovering that most of them considered maven as being the 'de-facto'
build tool these days - from chatting to people at the conference,
they mainly mentioned that maven was better as they didn't have to
think about getting started, whereas Ant provided much more
flexibility - in that vein, I think we should concentrate on Ant's
strengths:

- flexibility (add a scripting language would increase this significantly)

> +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.

Interesting, didn't think of that

>
> -1 (or <-1 if allowed) on writing our own DSL.
>

oh come on, it's mainly for fun ;)

> -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.
>

I understand, but my point is that some of the tasks we currently have
are less than optimal in both amount of code and in terms of
maintainability.  The more tasks we can specify in scripts/macro's,
the less maintenance effort there is (IMHO).

> -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,

Agreed that xml is a nice 'verbose' partner to Java (or C# for that
matter).  Lisp/Scheme would give us a very competent tool for deal
with trees (xml), without having to rely on xerces - although as Ant
is primarily used for building Java applications, a Lisp-Ant would
have to assume the presence of a jdk anyway, and in that case you may
as well write your tool in a jvm language (this doesn't preclude lisp
as Kawa runs on the vm)

> 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.
>

BeanShell is (IMHO) not a very big step from Java, it's almost as
verbose and provides very little extra in the way of abstractions.
JavaScript (Rhino), JRuby or Jython all offer a much higher level of
abstraction than Java and would be more accessible than Lisp.  As I
mentioned, I wanted to know what people thought about the idea of a
default script language for Ant, before suggesting an actual language
(I'd steer away from groovy before anyone suggests it ;))

[snip]

> for (jar in classpath.split(':;')) {copy({file: jar, todir: destdir})}

or

classpath.split(':|;').each { |jar| copy jar, dest }

> which anyone can read and understand at once. Furthermore it is trivial
> to see how to make a little modification to the above:
>
> for (e in classpath.split(':;')) {
>    if (e.endsWith('.jar')) copy({file: e, todir: destdir})
> }

classpath.split(':|;').each { |jar| copy jar, dest if jar.ends_with(".jar") }

[snip]

> TARGETS = [build, clean] /* build is first, so default */
>

Have you looked at rake?  This is a very good example of how a dsl for
builds can really help the expressiveness of your code

http://rake.rubyforge.org/

Kev

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[antoinell]

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: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Sat, 16 Sep 2006, Antoine Levy-Lambert <antoine@...> wrote:

> What about, if the members of ant-contrib were to agree to this,
> merge ant and ant-contrib to have the <if/> ...

Has anybody ever asked them?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Wed, 13 Sep 2006, Kevin Jackson <foamdino@...> wrote:

>> You'd be surprised how much less lines of code you'd need when
>> compared to the Java version, really.
>
> No really I wouldn't!  Java is a *very* verbose language, Lisp is
> probably one of the least verbose languages (apart from the ())

Actually Lisp isn't much less verbose, macros are the key.  And "real
macros" are what the other scripting languages I've looked into are
lacking.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Peter Reilly-2]

On 9/17/06, Stefan Bodewig <bodewig@...> wrote:
>
> On Sat, 16 Sep 2006, Antoine Levy-Lambert <antoine@...> wrote:
>
> > What about, if the members of ant-contrib were to agree to this,
> > merge ant and ant-contrib to have the <if/> ...
>
> Has anybody ever asked them?


<joke>I think that the author of <if> has been asked!</joke>
Peter

[Stefano Marsili]

Hi everybody,
I'm really no Ant expert, but I'm working on a project
that might be of interest to this thread.
It defines an expression language that extends
Ant's property expansion. At the moment the language
is limited and is still subject to heavy changes
(I like to experiment and I'm still learning Java ;-).

Anyway, an expression looks like this

  ${antx.prj getProperty(ant.version)}

which is the equivalent to Java's

  getProject().getProperty("ant.version");

It has some similarities with Lisp but it is also
a macro language:
the folowing function definition

  f=${func${#1}(${_str_}${_str_})}

if called with

  ${f(Name,str=A)}

evaluates to the call

  ${funcName(AA)}

So, it is just functions, no class definitions,
inheritance, etc., but it is highly customizable
and I hope will evolve.

If you're curious have a look at
http://www.efanomars.net/pf

Stefano Marsili


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[antoinell]

Hi,

Is Stefan the author of <if/> ?

Antoine
-------- Original-Nachricht --------
Datum: Sun, 17 Sep 2006 22:01:32 +0100
Von: "Peter Reilly" <peter.kitt.reilly@...>
An: "Ant Developers List" <dev@...>
Betreff: Re: suggestion : Ant 1.8 full dist to include a \'scripting lang\'

> On 9/17/06, Stefan Bodewig <bodewig@...> wrote:
> >
> > On Sat, 16 Sep 2006, Antoine Levy-Lambert <antoine@...> wrote:
> >
> > > What about, if the members of ant-contrib were to agree to this,
> > > merge ant and ant-contrib to have the <if/> ...
> >
> > Has anybody ever asked them?
>
>
> <joke>I think that the author of <if> has been asked!</joke>
> Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Sun, 17 Sep 2006, Peter Reilly <peter.kitt.reilly@...> wrote:

> On 9/17/06, Stefan Bodewig <bodewig@...> wrote:
>>
>> On Sat, 16 Sep 2006, Antoine Levy-Lambert <antoine@...> wrote:
>>
>> > What about, if the members of ant-contrib were to agree to this,
>> > merge ant and ant-contrib to have the <if/> ...
>>
>> Has anybody ever asked them?
>
> <joke>I think that the author of <if> has been asked!</joke>

You've probably spent far more time on <for> than I spent on <if>
which was zrivial to write.  Sure, we could re-write those tasks
pretty easily.  Neither of us is a project admin, though.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Stefan Bodewig]

On Fri, 15 Sep 2006, Jesse Glick <jesse.glick@...> wrote:

> -0.5 on Lisp or Scheme.

I don't think anybody around here was more than half-serious.

> Don't get me wrong, I probably would have been miserable as a
> teenager were it not for CLtLR2.

?

> Now <copy> can take a fileset, but you have a path, not a fileset,
> and there is no root.

You certainly know that 1.7 can copy paths just as well.

> for (jar in classpath.split(':;')) {
>   copy({file: jar, todir: destdir})
> }

demonstrates my biggest problem with using a scripting language
instead of something abstracted away from scripting (like our current
XML format).  You start to use the scripting language where you don't
need it.

We've not only built file up-to-dateness checks into most task, we've
also made most tasks perform those loops implicitly.

for (src in srcDir.scanRecursively()) {
    if (src.endsWith(".java")) {
        javac({src: src, todir: destDir});
    }
}

would be horribly inefficient, and probably be what many people new to
ant would use.  And I don't really think the above is more readable
than

<javac srcdir="${srcDir}" destDir="${destDir}"/>

> which anyone can read and understand at once.

I'm not sure.  Any user with at least a little programming background
can, but Ant is used by people who don't have such a background at
all.  By hiding away as much of the procedural code as possible (OK,
we might be able to do even more) we've attracted a brader set of
users.

> If targets were replaced by functions, and <import> by load(...),
> you could compose scripts as normal library files, without having to
> sweat over idiosyncratic inheritance and naming rules in the Ant
> manual, not to mention the confusing ways that properties and
> references are passed to subscripts, which does not match the
> semantics of any real language.

We've defined a new language with Ant without noticing what we did.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[foamdino]

> On Fri, 15 Sep 2006, Jesse Glick <jesse.glick@...> wrote:
>
> > -0.5 on Lisp or Scheme.
>
> I don't think anybody around here was more than half-serious.

I was more than half serious, but not as part of Ant, more as an
interesting side project

>
> > Don't get me wrong, I probably would have been miserable as a
> > teenager were it not for CLtLR2.
>
> ?

Common Lisp the Language Release 2 (I guess)

[snip]

> demonstrates my biggest problem with using a scripting language
> instead of something abstracted away from scripting (like our current
> XML format).  You start to use the scripting language where you don't
> need it.
>

ok that's a fair comment, but there are times when you really need the
full expressiveness of a language (of whatever kind, I view build
files as a declarative language).  Right now we are missing a few
control structures which may only be used from time to time, but give
a lot of expressive power - antcontrib to a certain extent fills that
void.

I still stand by my assertion that Ant should include scripting
support out of the box, and my preference would be to support rake
style syntax ala

http://www.martinfowler.com/articles/rake.html

Because basical