ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: PATCH: Attributes of Target can reference properties
Date Tue, 03 Jul 2001 17:24:56 GMT
On Wed,  4 Jul 2001 02:03, Peter Vogel wrote:
> I'm not after "generic" rules (i.e. of this form:
>
> .o.s:
>      asm ...
>
> But rather, I am after having a set of targets which define the
> "standard" way of doing a few things and then allow an individual
> build to extend that if necessary (i.e. we have one system that
> needs to do a few "extra" things to generate .java files before compiling,
> so it has a "local.precompile" that the standard "compile" target
> depends on as a result of defining a property.  The average build.xml
> file sans comments is 6 lines long (comments make it about 30).

That still saids generic rules to me. And Generic Rules == Templates in my 
mind. The only difference is the level abstraction. In make it is largely at 
the file level while in ant it is at TaskModel level. 

> > Ant2 will allow
> > you to customize to your hearts desire by simply dropping a
> > jar in place. So
> > if you still believe the stuff you say and are willing to
> > walk the walk
> > rather than talking the talk then you can do it.
>
> I'm not sure I understand what you mean about the talk and
> the walk, 

well effectively you will be able to create your own ProjectBuilder or 
Workspace or whatever with a simple change of a property (The current 
myrmidon proposal actually autodetects based on file extension). So whatever 
wierd and wonderful model you dream up you can do.

> but part of what I want to avoid is the idea that
> it is ok to create a gazillion tasks as part of a build infrastructure,

agreed.

> there are some places where a task (or a few tasks) are completely
> appropriate, for example building installation packages. But there
> are others where a "roll your own" philosophy detracts from the goals
> of ant.  I'm quite happy to write tasks, etc. to meet my needs, and
> I have done so where I felt it was appropriate.

right.

But neither of these points have any correlation with your point. Your 
contention seems to be that we should add flow control tasks and their 
ancillary support. This would in effect determine structure of build at 
runtime rather than before execution began. It would also have a number of 
side effects. Yet the only reason for using this above something like XSLT is 
that you don't want to learn XSLT. Naturally this is not an arguement that is 
going to convince me.

> > but it is not Ant.
>
> Isn't this *exactly* what JDD (original designer of ant) said about many
> of the things that have been discussed on this list and are likely to be
> in ant2 prior to getting shouted out of the community in January?

Yep but the difference is he isn't here to veto any of those changes - I am ;)

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

Mime
View raw message