ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: Configure->Template->Build
Date Wed, 06 Jun 2001 15:04:47 GMT
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".

> You suggested keeping T1 and T3 in the "template" project file
> (P2). T2 would be replicated in each of these build files (P1) that
> need it.
> You never specified how the dependency would be managed

I never gave it any thought would be closer to it 8-).

> (A) the template file T1 is dependent on T2. This means every
> buildfile has to have a T2 and it must depend on T3.

This sounds like "project inheritance" - no I wouldn't like that.

> (B). T1 does not have any dependencies. You create a dummy target in
> in P1 that depends on T1, T2 if necessary and T3. This would rely on
> serial processing of dependencies.

This is how it could work, yes. serial processing will be available in
Ant2, so no big deal.

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

> So moving to your templating solution

It is not *my* templating solution.

> The other solution you offered was that we mandate that any tasks
> that take input will not operate if their input set is null or
> empty.

Not true. I jumped to your particular example and said that you
wouldn't need any processing at all - apart from defining patternsets
for the files you want to get compiled, rmiced or copied - and that
these tasks are smart enough to do nothing if there is nothing to do.

But yes, this is my general vision of Ant - make the tasks smart and
keep the core simple.  I wouldn't mandate any behavior for tasks but
those acting on filesets will have the "no-input no-result" policy
almost automatically.

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

> Besides this means far too much maintanence work for us to keep all
> tasks operating according to our 'golden' rules.

Nope, no rule, no maintenance.

> 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


View raw message