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:20:47 GMT
At 07:48 AM 6/6/01 -0700, Roger Vaughn wrote:
>--- Stefan Bodewig <> wrote:
>> I agree - and I think Peter does as well.  The
>> thread started out with
>> Peter asking which combination of tools he should
>> use to create his
>> prototype - so we can evaluate the impact - and
>> somewhere down the
>> thread I said I wouldn't care too much ...
>Ok, I'll accept that.  It just seems that the disc.
>has turned to "is it right or not".  Peter *seems* to
>argue that <projectref> is "wrong" or "bad" 

projectref as described by Jose *is* wrong ;) projectref as originally
defined is right (and needed).

>- and my
>point of view here is, if it doesn't change the core,
>it isn't bad.  If you don't like it, don't use it.  I
>have NO problem with that.

It does change the core but even if we didn't we don't subscribe to that
philosophy (for better or worse). If we did the many foreach/if/case tasks
that have been created would be included in the core.

>> Most of the problems people have with Ant - at least
>> those people
>> asking for loops and such - stem from the fact that
>> they are trying to
>> make Ant fit the paradigm they've been using in
>> their respective build
>> systems before they switched to Ant IMHO.
>Not necessarily.  That's one issue I have with some of
>these discussions.  You can't automatically make that
>assumption.  I will agree that in many cases, you are
>correct, but there are still cases such as myself who
>*have* shifted gears but still want new features (such
>as iteration).  It happens that the Ant syntax
>encourages the use of iteration, etc. in certain
>circumstances since the Ant targets do not operate
>directly on files.  There are cases and files which
>are not currently covered by tasks (eg. non-Java
>files) that could be handled more elegantly with some
>of these features we ask for.  (And no, I don't have
>an example ready at hand - I'm just on my soapbox.)

theres plenty of examples - I agree 100% with need. I was ... *educated*
... about it's usefulness recently. It is how the functionality is provided
that is the tickler.

>It seems a central issue of many of these discussions
>is the composition of the target market for Ant -
>novices or experts.  My target audience is of course,
>myself, expert.  But I certainly can't dictate that to
>the team!  ;-)  Perhaps clarifying who Ant is intended
>for would help keep some of these disc. from getting
>antagonistic.  (There it is again - ant-agonistic.)

in my eyes templates will be 90% for people like you and not of real use to
novices or small/simple projects.

>> If we have some static templating mechanism I
>> strongly wish that we
>> brand it as "this is not Ant".
>Agreed.  I have used XSLT "templating" myself, and I'm
>very happy with the way it lets me assemble simple new
>pseudo-tasks in much less time than it takes to write
>the Java.  However, as Jose pointed out, there is a
>huge danger of Ant fragmenting into a different local
>"dialect" for every project out there.  

I am not sure that is a bad thing ;) 

>I also think
>external templating (or configuration) carries a much
>greater potential for abuse from careless programmers
>(which Peter is concerned about) than do most
>potential new Ant features.

could you clarify?

>If this fragmentation occurs, then no one is using
>"Ant", but rather their local build language.  No, you
>can't call that Ant.  Also, Jose's points about the
>effect on Ant generators and editors is an excellent
>one that I had not previously considered.  (Probably
>because I don't like generators much myself.)

I don't think generators/guis should be fezzing with template files. The
templates are written by experts who presumably know what they are doing
and can work better in a XML editor (or text editor).

>IMHO, any approach that treats Ant the same way will
>most likely meet the same reception.  Any solution
>that requires additional languages to complete the
>build will be necessarily more complicated to learn
>and maintain.  For that reason alone, I personally
>would rather see the Ant core language itself become
>more expressive.

possibly but that makes everyone pay for the power regardless of whether or
not they use it. Personally I would like to have if tasks for use in
templating. Providing this feature would inevitably lead to misuse by users
who shouldn't be using it. So while it would be nice for me to use, it
would cause pain to less experienced users, thus I would never support it's
inclusion in core.



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