Peter Donald <[EMAIL PROTECTED]> 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 templates"? Stefan
