ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: Configure->Template->Build
Date Wed, 06 Jun 2001 15:02:02 GMT
At 06:23 AM 6/6/01 -0700, Roger Vaughn wrote:
>The fallacy here is that you assume there is one
>"right" way to write Ant scripts.  What works for you
>may not be right for others, and vice versa.  In some
>circles, any solution, no matter how ugly, is the
>right one (I'm not one of these :-)).  We need to
>recognize that people think different ways, solve
>problems different ways, 

agreed. But we don't support this style of interaction or at least not a
last count. A phrase I often utter is "The road to perl is paved with good
intentions" which kinda illustrates that point.

>and will run into build
>scenarios that this team, I, or anyone else on the
>list cannot anticipate.   (Hmmm, ant-icipate.  An Ant
>preprocessor?  Sorry, couldn't help it. ;-))

which is exactly why we should base our work on tested, and well used
patterns from people with globs of experience in this area.

>To my way of thinking, the discussion should not
>center around whether templates (dynamic or static)
>are "the right thing to do", but rather around how
>they impact, positively or negatively, the Ant core
>and therefore the structure and behavior of *all* Ant
>scripts.  There is obviously demand (and therefore
>need) for this type of functionality, so who are we to
>say it is "wrong"?  If, however, implementing
>templates would compromise the Ant core (once again,
>the core code, *not* the "correctness" of scripts),
>then it can be said that Ant will not support them.

The way I propose it requires little (actually 0) extra support from the
core. As long as Conor lifts his -1 from ProjectBuilder concept there needs
to be nothing changed.

<projectref ... /> as argued for by Jose also requires another
ProjectBuilder but to maintain semantics, needs runtime support aswell. It
requires the ability to modify project model at runtime and do other
similar things. 

<projectref ... /> as originally defined (which I am +1 for) also requires
adaptions to core. I don't think we have agreed to allow properties to be
exported so I believe the only extra support would be managing scope of

>It appears to me that <projectref> is a workable

which projectref design ? ;)

>solution.  Implemented as a task, it has very little
>impact on the Ant core.  Now, I have to say I'm not
>thrilled with the idea, because as Peter points out,
>it does break out functionality into many separate
>files.  (However, I fail to see how XSLT templating
>and configurators don't also do the same.  Sure, you
>can try to read the generated script, but it isn't fun
>- at least not without reformatting it first.)  I
>would prefer a templating solution that allows (not
>forces) the build engineer to put everything in one

I am curious why you would want this (you are build engineer right?). Most
of the people who I talk to separate rules/templates into a different file
from data at the very least. Some also insist on maintaining separate
configuration data. 

The main reason is that I see templating only being of use to large
projects. In this case you want to reuse rules/template in many project
files. Most of the people I spoke to were developing mixed systems of
java/CORBA/c with various apps from web-GUIs to native GUIs, to swing GUIS
etc. I even found a cons user to query - yaya - not that I understood all
he said ;)

>However, since this would definitely have a big
>impact on the Ant core, I would have to say that
><projectref> is probably the better idea.

I think you have it backwards. Projectref as advocated by Jose does have
the greatest effect on the core. It effectively ties us into one project



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

View raw message