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 16:23:15 GMT
At 05:04 PM 6/6/01 +0200, Stefan Bodewig wrote:
>Peter Donald <> wrote:
>> Okay the problem is that certain features occur in certain builds
>> but not in others. If they are included then they are present in
>> very specific and well known places in build file. Lets call this
>> feature F. Each F occurs in a target T.
>> Your solution to this was to split T into T1, T2 and T3.
>This was one solution and in the specific rmic case I even said "But I
>don't suggest that".

I must of missed that ;)

>> Now lets assume that each project if it was not using templating
>> would have 10 targets. Lets assume that we have 20 projects. In
>> these 20 projects there are variations, some use rmic, some
>> obfusicate, some build ejb jars, some build wars etc. Lets set the
>> variation count at 10 (which I think is an underestimating
>> variation).
>You think these projects are still similar enough to all be generated
>from a single template?

yup - in most cases they are almost identical with search&replace of
name/copyright/year values (which should probably be stored in property
file anyway) and then add in a few chunks of text.

>> This may work for a subset of cases but there will still be tasks
>> that don't take input that are an F.
>These would be a problem, sure.  How many features of the ten
>variations would you expect to be of that type?

In the example cases I was thinking of - none - but I can think of cases
where this is not so ;)

>> While XSP/JSP can be almost as nice by only using taglibs, this
>> isn't forced by language so it relies on good sense and knowledge of
>> developer (a bad idea IMO).
>Doesn't your static templating model rely on good sense and knowledge
>of the build file writer to know when he/she doesn't need templates?
>> Remembering that the situations that mandate templates will
>> generally also mandate the presence of configuration/build
>> engineers.
>How will people know they are in a situation that "mandates

Well put bluntly, going from regular ant to templated ant is a large step.
The users have to at least learn the templating language (whatever it is)
and they have to think in terms of rules and data. The initial setup costs
of templating is high and benefits come only if there is multiple projects
using rule/template file. 

Outlining this in documentation combined with higher barrier of entry
should discourage casual users. If they still want to do it then; 
* they aren't going to listen to us anyway
* actually know what they are doing

If we can thinking of way of discouraging use even more then that would be
great (but I can't).



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