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:[EMAIL PROTECTED]]
> > Sent: Thursday, June 21, 2001 9:47 AM
> > To: [EMAIL PROTECTED]
> > 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
> > > [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
> > 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 |
*-----------------------------------------------------*
