You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2001/09/11 11:03:32 UTC

Re: [PATCH] Added "ant.target.name" property

On Tue, 28 Aug 2001, Kyle Adams <ka...@gfs.com> wrote:

> The following patch allows the user to access the current target
> being executed by using the ${ant.target.name} variable.

I have no problem with applying the patch myself, but I remember Peter
Donald vetoing something like this on ant-user a while back.  Am I
correct, Pete?

Stefan

Re: on evil practices

Posted by Alejandro Abdelnur <al...@sun.com>.

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

Re: on evil practices

Posted by Peter Donald <do...@apache.org>.

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

Re: howTo call an external process

Posted by Stefan Bodewig <bo...@apache.org>.

On Wed, 12 Sep 2001, detlef brendle <de...@canoo.com> wrote:

> I need to call an external process from within my Java program and
> parse the outputstream of the process.  What sort of built-in
> wrappers does ant have for this kind of task ?

Take a look at org.apache.tools.ant.taskdefs.Execute - this class
encapsulates the platform and VM specific logic of executing system
commands in an arbitrary directory and is used by several built-in
tasks (including <exec> and <java fork="yes">).

Stefan

RE: howTo call an external process

Posted by Ingmar Stein <st...@xtramind.com>.

Hi Detlef,

rtfm.
Use the exec task to start your external process. The record task
will catch the output. All you have to do is to write a task that
does the parsing.

Cheers,

Ingmar

> -----Original Message-----
> From: detlef.brendle@canoo.com [mailto:detlef.brendle@canoo.com]
> Sent: Mittwoch, 12. September 2001 08:24
> To: ant-dev@jakarta.apache.org
> Subject: howTo call an external process
> 
> HI,
> I need to call an external process from within my Java program and
parse
> the
> outputstream of the process.
> What sort of built-in wrappers does ant have for this kind of task ?
> 
> 
> detlef

howTo call an external process

Posted by de...@canoo.com.

HI,
I need to call an external process from within my Java program and parse the
outputstream of the process.
What sort of built-in wrappers does ant have for this kind of task ?


detlef

Re: on evil practices

Posted by Alejandro Abdelnur <al...@sun.com>.

bevan,

i agree with your perception of ms-word, that is why i use it only as a
word processor, the difference here is that it's my choice to do so. i
do not like to be constraint because somebody else thinks is dangerous,
let me shoot myself in my foot if i'm stupid enough to.

i know that there have been long discussions about things of the sort in
the past and i have no intention to start a new one.

the changes [i was asking for in my previous email] are to allow
developers (in this case myself) to use alternate implementations of the
Project, Target and ProjectHelper classes, nothing changes in the
surface of ant, but enables developers (again, in this case myself) to
extend Ant to their own needs without having to modify the ant core thus
having to retrofit changes with every new version of ant (already done
that from 1.2 to 1.4).

thxs and regards.

a

Bevan Arps wrote:

>  At 17:52 11/09/2001 -0700, 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.
>
>
> The key here is "trimming the capabilities or the power of expression"
> of Ant.
>
> There are always decisions to be made in the development of any tool.
> One of the most important areas is to decide what the tool shouldn't
> do.  Any application that tries to be a Swiss-army-knife or a
> jack-of-all-trades inevitably ends up being a poorer tool.
>
> A great example here is MS Word - which tries to be Word Processor,
> Desktop Publisher, Content Reviewer, Document Designer, Mail Client
> (and more) all rolled into one. The first it does extremely well - the
> others less so.
>
>
> The specific functionality that has been rejected from Ant seems, to
> me, to fall into two categories:
>
> -- Shortcuts to functionality already present
>
> Rejecting these doesn't reduce the power of Ant in any way - and does
> serve to keep Ant simple. A good example here is the presence of
> if/unless attributes on the fail task.
>
> -- Dangerous Features
>
> ie Functionality that provides a moderate level of increased ability
> at the expense of great danger.
>
> One common problem common to any tool is the fact that new users tend
> to blame the tool for their own mistakes or misunderstandings. Make a
> tool with too many Dangerous features and new users will find the tool
> too quirky and discard it, looking for something simple.
>
>
> I applaud the Ant Team (take a Bow, all of you) for having the courage
> to "keep the vision".
>
> I might (in fact I do) disagree with some of their decisions - however
> I can't ignore the fact that it is their dedication to "what might be"
> that has given us such a fine tool.
>
> My 3c,
> Bevan.

Re: on evil practices

Posted by Bevan Arps <be...@actfs.co.nz>.

At 17:52 11/09/2001 -0700, 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.

The key here is "trimming the capabilities or the power of expression" of Ant.

There are always decisions to be made in the development of any tool. One 
of the most important areas is to decide what the tool shouldn't do.  Any 
application that tries to be a Swiss-army-knife or a jack-of-all-trades 
inevitably ends up being a poorer tool.

A great example here is MS Word - which tries to be Word Processor, Desktop 
Publisher, Content Reviewer, Document Designer, Mail Client (and more) all 
rolled into one. The first it does extremely well - the others less so.

The specific functionality that has been rejected from Ant seems, to me, to 
fall into two categories:

-- Shortcuts to functionality already present

Rejecting these doesn't reduce the power of Ant in any way - and does serve 
to keep Ant simple. A good example here is the presence of if/unless 
attributes on the fail task.

-- Dangerous Features

ie Functionality that provides a moderate level of increased ability at the 
expense of great danger.

One common problem common to any tool is the fact that new users tend to 
blame the tool for their own mistakes or misunderstandings. Make a tool 
with too many Dangerous features and new users will find the tool too 
quirky and discard it, looking for something simple.

I applaud the Ant Team (take a Bow, all of you) for having the courage to 
"keep the vision".

I might (in fact I do) disagree with some of their decisions - however I 
can't ignore the fact that it is their dedication to "what might be" that 
has given us such a fine tool.

My 3c,
Bevan.

--
"Programming is an Art Form that Fights Back"

Bevan Arps (<ma...@actfs.co.nz>bevan.arps@actfs.co.nz)
Senior OO Analyst, ACT Financial Systems

This communication  is confidential  to ACT  Financial  Systems  (Asia 
Pacific)  and is intended for  use only by the  addressee.   The  views and 
opinions  expressed in  this email  are the senders  own and do not 
represent  the  views  and  opinions of  ACT  Financial  Systems  (Asia 
Pacific).

on evil practices

Posted by Alejandro Abdelnur <al...@sun.com>.

i've been in this alias for just a  couple of weeks, and i've already seen
replies to requested features on the tone of the one below.

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.

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

so, for most of my proposals, i've re-implemented them as new tasks
(extending the original ones) -i.e. xproperty, xantcall, xfilter. i'm happy
with this approach as it let me do my *evil practices* without having to
modify the core.

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.

i do not think that making the Target, Project and ProjectHelper classes
configurable does directly increase the evilness of ant but it would
simplify the porting of custom features to future realeases of ant.

i hope you consider making the implementation of Target, Project and
ProjectHelper configurable, and i would be glad to take on the
responsibility of making the changes if you agree to them.

thxs and regards.

alejandro.

Peter Donald wrote:

> On Tue, 11 Sep 2001 19:03, Stefan Bodewig wrote:
> > On Tue, 28 Aug 2001, Kyle Adams <ka...@gfs.com> wrote:
> > > The following patch allows the user to access the current target
> > > being executed by using the ${ant.target.name} variable.
> >
> > I have no problem with applying the patch myself, but I remember Peter
> > Donald vetoing something like this on ant-user a while back.  Am I
> > correct, Pete?
>
> yup - encourages evil practices ;)
>
> --
> Cheers,
>
> Pete
>
> ---------------------------------------------------
> "Marriage, Friends, Religon -- these are the demons
> you must slay in order to suceed in business.."
>                  -- Mr. Burns, The Simpsons
> ---------------------------------------------------