ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: Configure->Template->Build
Date Wed, 06 Jun 2001 15:46:57 GMT
> From: Roger Vaughn [mailto:rogervaughn@yahoo.com]
>
> --- Stefan Bodewig <bodewig@apache.org> wrote:
> > 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.)
>

I agree with you here. I have no problem with attempts to have a more
general way to apply tasks to filesets. I may not be sure or agree with just
any implementation (given my strong views about property mutability, for
example). But to me such capability will improve readability and clarity of
buildfiles.

> > My major concern here is: Give them static templates
> > and they don't
> > even bother looking up another way of doing what
> > they need with Ant.
> > They'll talk about the complexity of XSLT and say
> > Ant would be
> > difficult to learn and all that.
>
> I have to agree with your point, but on the flip-side,
> many of those same people will never make the effort
> to learn XSLT or any other solution, either.  I would
> bet that such things would probably never even occur
> to them.  In response, they will end up writing
> horrible Ant files.  Is it really the team's charter
> to prevent that from happening, or is it instead to
> ensure that 90% of build file writers *can* write
> clean files?
>
> 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.)
>

I have no vote, but I think we should try to maintain ANT as accessible as
we possible can without taking that as an impediment for needed features. I
think we can provide 95% of what is required without requiring a different
programming model (being XSLT, Anakia, JPYTHON, or JavaScript). For the rest
5% that is required by experts in very complex systems, I think those
features can be provided by tasks. And being in tasks isolates them from ANT
the language into its own thing. I see that as a very legitimate model.

My problem with the proposal is that it can become the cannon with which we
tell people to solve every problem. We have being using it already, for the
last year many times when someone asked how to do this or that, or why not
having a taask to do this or that, the answer was "oh, this issue will be
solved by templates". Which means we will be forcing people into templates
one way or the other and hence the branding of whatever preprocessor we
provide as ANTs preprocessor and ANT's difficult language.

>
> Even though I have used the XSLT approach and do like
> it, I am expert at this stuff.  I cannot see
> recommending it for widespread use, as it is
> remarkable similar to the Imake debacle.  Imake is a
> powerful tool, but saw very little use because of its
> complexity, not the least of which was the use of
> three separate languages (the Imake "language" - cpp,
> the make language - itself incorporating several, and
> the local dialect Imake was to process).
>
> 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.
>

Yeap. This was exactly the reason I jumped into making my views knows about
autoconfig/Imake model. And hence all this discussion.

Jose Alberto


Mime
View raw message