ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alejandro Abdelnur <alejandro.abdel...@sun.com>
Subject Re: on *evil practices*
Date Wed, 12 Sep 2001 03:37:21 GMT
peter,

the thing is, i did some improvements to ant that i found useful, i wanted to
share them with the ant community, that they are not accepted for the core it's
fine, but the thing i wanted  (and as you say it will be in ant 2) was more
flexibility in the core so it is possible to extend ant without having to tweak
it.

i'm not a big fun of scripting languages, mostly because they are loosely typed.

i do not like embedded languages at all, c-sql, html-javascript, or javascript
into an Ant build file.

some of the stuff that i've proposed was:

1* property value overriding thru a new "override" attribute.
2* embedded property name resolution, i.e: ${a${b}}
3* target if and unless attributes to support property values, i.e:
if="server.type=tomcat"
4* antcall iterations using 2 new attributes (iterate and iterator)
5* DEFAULT target for non existent targets

after the rejection for 1 and 4 i've implemented the xproperty and xantcall tasks
(extending the original ones) to do so, but for 2, 3 and 5 i have to modify
Target, Project and ProjectHelper because they are not pluggable.

you mentioned that this pluggability will be in ant 2, great, i'll be looking
forward to it.

i've implemented a comprehensive development environment for big project (80+
developers) and with the features described above i managed come out with a
modular set of 9 ant files, of a page long each. they build,deploy and install
j2ee apps and it's easily customizable thru properties files without touching the
ant files.

regards

alejandro.

Peter Donald wrote:

> On Wed, 12 Sep 2001 10:52, Alejandro Abdelnur wrote:
> > i do not think that the way of avoiding *evil practices* should be achieved
> > by trimming the capabilities or the power of expresion of Ant but by
> > provinding guidelines on how to use things. always there are things that
> > look like *evil practices* to purists but are needed by a real task.
>
> Just becase you can doesn't mean you should. I am sure we could increase the
> expressiveness of ant by allowing perl expressions + lisp/tcls command
> constructs. At the same time we could throw away the xml format as that is
> waaaay too verbose.
>
> BTW do you think java is a weak language because it doesn't allow the
> expressiveness of pointers?
>
> > in my personal case, the enhancements i've proposed in the last weeks have
> > been rejected because of similar reasons -ant would become, or would be
> > used, as an scripting language-.
>
> theres already enough decent scripting languages out there (javascript, tcl
> and python being my favs). If you want a scripting language it would seem
> that you should use a real scripting language because you will never be
> satisfied with ant.
>
> > however, for some of the changes i did need to tap some code into the
> > Project and Target classes, but in the way these classes are instanciated
> > they are not pluggable. i've modified the code so the implementation of
> > Project and Target being used is defined in an ant/defaults.properties
> > file. i would need the same for the ProjectHelper class, but in this case
> > is a little more complicated as the static methods should be made instance
> > methods and this requires some change all over the place.
>
> All these things will be pluggable in Ant2 but in Ant1.x it seems unlikely.
> The reason is that it would probably require backwards incompatible changes
> which we are loath todo at this stage. That said I haven't had the time to
> proppely look at your changes yet so ...
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> For every complex problem there is a solution that
> is simple, neat and wrong
> ---------------------------------------------------


Mime
View raw message