ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: for-each (another proposal)
Date Fri, 22 Jun 2001 03:07:43 GMT
On Fri, 22 Jun 2001 03:30, Brett Knights wrote:
> My main reason for proposing something like this is that you need to be
> able to manipulate the arguments to tasks based on what they need. For
> instance I went to use the execOn task (IIRC) to call an external procedure
> once for each of a group of files. I needed to pass an argument as
> -i{filename} but there was really no way to do that. While I could have
> patched that task for my particular need (and in this case I ended up
> patching another task) I don't think we want to have to patch tasks
> whenever they don't do quite what we want. There are likely many external
> tools that take a particular set of arguments that we can't anticipate at
> present.

I missed your original post (snarl at my mail server I think) but I think I 
agree with your approach. Unfortunately at this stage neither what you 
describe (what I called templating) nor a set of tasks like foreach will ever 
reach ant's core.

if you are familiar with the 2 outa 3 rule - that applies here. You may be 
familiar with this rule from a "joke". For instance when making something you 
can;
* make it fast
* make it cheap
* make it good
 
Of course you can only achive two of those goals and must accept the other 
factor. The same thing is present in natural language theory and carried 
across into formal language theory it goes something like;
* make it simple
* make it expresssive
* make it extensible

You cannot have all three. Ant originally selected "simple" and "extensible" 
and thus have to live with the fact that it is not always able to express 
certain things.

The opinion of some ant devs is that you need to simply add more tasks. Need 
something new then add a task. This is of course a bad design choice as you 
end up with oodles of project specific task or ugly build file hacks. (Look 
through this list and antdev and you will see lots of complaints when people 
try to do complex things and find it difficult).

Other people are in favor of adding all sorts of logic/flow-control operators 
straight into core (or as tasks). This of course would mean ant is now 
expressible and extensible but not simple. Considering that a lot of build 
scenarios I setup are for less technically orientated people, I will veto any 
such suggestion. However without this type of functionality people are going 
to complain that build files are not reusable or are too verbose etc. (ie 
look at questions people ask in hopes of implementing generic 
scripts/targets).

So what would be the solution? Like you I though separating it into another 
layer would be optimal. It keeps the core clean and simple but gives advanced 
users as much functionality they need (or rope as they need to hang 
themselves). 

My strategy was slightly different - I keep the xsl is a different file. 
Mainly as that would allow the same "rules" file to be reused by multiple 
projects. The myrmidon proposal in CVS allows you to xsl the input file if 
xsl file exists beside build file (bad design but it was a hack to test 
things). I was thinking about making the stylesheet work via PIs like

<?xml-stylesheet href="my-rules.xsl" type="text/xsl"?>

however am still playing. 

The one thing I am concerned about is the number of extentions that could be 
added. I have watched other projects use an excessive amount of extentions 
that effectively make xsl a new language. This of course makes it impossible 
to read - even for other xsl developers unless they are familiar with 
extensions.

Something like this will be offered for ant2 - just not from this website.

> > -----Original Message-----
> > From: Larry V. Streepy, Jr. [mailto:streepy@healthlanguage.com]
> > Sent: Thursday, June 21, 2001 9:47 AM
> > To: ant-user@jakarta.apache.org
> > Subject: Re: for-each (another proposal)
> >
> >
> > I'm opposed to this for one main reason: it forces me to
> > study and learn
> > XSLT just do to something trivial like "foreach".
> >
> > Brett Knights wrote:
> > > Consider this:
> > >
> > > <taskTransformer> <!-- as it's not just a for-each (name
> >
> > suggestions gratefully accepted)-->
> >
> > >   <elements row-elem-name="file"> <!-- this will become the
> >
> > xml source that will be passed to the stylesheet -->
> >
> > >     <fileSet .../>
> > >   </elements>
> > >
> > >   <taskStyle>
> > >   <!-- everything in here is treated as a template that
> >
> > would normally be defined as <xsl:template match="/" -->
> >
> > >     <xsl:for-each select="file">
> > >       <touch file="{ant:full-path(.)}"/> <!-- anticipating
> >
> > some ant specific extensions. The example could use file="." -->
> >
> > >     </xsl:for-each>
> > >   </taskStyle>
> > >
> > >   <templates>
> > >   ... <!-- optional section if further templates are required -->
> > >   </templates>
> > >
> > > </taskTransformer>
> > >
> > > It's not a great deal different than each of us writing a
> >
> > scripted task when we want to run over a set of files except:
> > >  - we can still use fileSets rather than relying on our
> >
> > scripting language's file system access routines.
> >
> > >  - any task could be used in a for-each mode without modification
> > >  - what is produced is used as though the fully transformed
> >
> > version had appeared in the original build.xml
> >
> > >  - the full power of xslt is available should it be needed.
> >
> > (and is there to bite you ...)
> >
> > > The task would assemble the included elements into a
> >
> > stylesheet that would import a standard stylesheet (therefore any xsl:
> > > directives in the build.xml would override the standards).
> > >
> > > One nice thing about the xslt route is that xslt is already
> >
> > fully documented. :-)
> >
> > > There is enough work here that I won't just code it up,
> >
> > submit it, and see if it makes it. If this seems viable to
> > others and  has a
> >
> > > chance of making it into official Ant I'll take on
> >
> > developing it though. (At which time I guess further
> > discussions would go on the
> >
> > > Ant-Developer's list)
> > >
> > > ***********************************************************
> > > Brett Knights                             250-338-3509 work
> > > brett@KnightsOfTheNet.com                 250-334-8309 home
> > > ***********************************************************
> >
> > --
> > Larry V. Streepy, Jr.
> > Chief Technical Officer and VP of Engineering
> >
> > Health Language, Inc.  -- "We speak the language of healthcare"
> >
> > 970/626-5028 (office)           mailto:streepy@healthlanguage.com
> > 970/626-4425 (fax)              http://www.healthlanguage.com

-- 
Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*

Mime
View raw message