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 Tue, 29 May 2001 13:24:59 GMT
> From: Peter Donald [mailto:donaldp@apache.org]
>
> At 03:56 PM 5/28/01 +0100, Jose Alberto Fernandez wrote:
> >I got to say, I am very -1 on going the way of make and
> getting on the
> >bussiness of an autoConfig sort of way of solving problems.
> I do not see the
> >need for that.
>
> You have said that a couple of times but never given any
> reasons. Can you
> give some reasons.
>
> Without this we will require that ant include
> if/case/condition/* style
> tasks that are a declared non-goal. Simply because we need
> the flexability.
> I have already had to fight often enough with some of ants
> rules that it
> gets painful for large projects.
>

With this *YOU ARE* adding if/case/condition* to ANT. Even more you are
adding an additional syntax and semantics for writing buildfiles. Lets face
it, if it is jakarta-ant defined and maintained, it is ANT.

The beauty of ANT is its simplicity which allows peoples to understand ANT's
files with only basic knowledge of ANT itself. This new language for
autoConfig will break that, and I think that is bad. I definetly do not want
to have 100 pages of the ANT documentation explaining how XSLT templates
work. Certaintly there are books dedicated to the subject that are fatter
than that, so it is not just a retorical statement.

> As most committers agree that making ant a script language is
> a bad idea
> then we have a problem. Certain stages of build process need
> ad-hoc logic
> (aka scripting) - namely the first stage of detecting
> environment. So we
> either make people jump through loops (yuck), add scripting
> to ants core
> (yuck) or make it accessible through another stage (yea!).
>

How is a pure Java autoConf going to solve this. I mean where are all this
configuration parameters for the different configurations comming from.
Aren't you just trying to add conditionals in desguise? Can you give
examples of the kinds of real world issues that you think can only be solved
properly by autoConf?

> So if you can think of a way to solve the problem then we throw away
> separate configure stage. If you can convince the committers
> that we don't
> need to support complex build environments then we can
> throwaway the stage.
> Otherwise I can not see any other alternative considering the
> goals of ant.
>

Can you provide some realistic scenarios? What is what you think is
impossible (or very unintuitive) in ANT (or ANT2's proposal). My current
thoughts about it is that people feel autoConf is needed and fill includes
and mutable properties are needed because we are use to MAKE and the
patterns developed over time for MAKE and we want to apply those same
patterns in ANT. I would argue that ANT has (or will develop) its own
patterns in which mutable variables, textual includes, and I think autoConf
are not needed.

This, of course, involves a paradigm shift of proportions I don't really
know. But I think this is a very important aspect of the ANT future success.
Like with any other programming tool, the success of maintainability and
expressibility relies on the patterns of best practice developed for them.

> >I see the ability to write cryptic files that are only 3
> lines long and from
> >that produce a 50 pages long ANT file, to be king of outside
> ANTs goals.
> >
> >Now providing a hook or something for those who really want
> to go that way,
> >well I may be convinced of that, but as such we shouldn't be in the
> >bussiness of deciding what technologies they should or they
> should not use.
> >They should be on their own on that.
>
> thats ludicrous. Imagine if every user of make had to make up
> their own
> version of automake/imake/autoconf/whatever. There is already too many
> choices in that area. Hopefully we will recomend and support
> one method but
> if peeps want to do it another way then that is also fine.
>

So, should antidote add to its charter the development of a full fledge XSLT
template editor? That will keep them busy for a while :-)

No one is saying every user will have to write their own system. I am saying
such things should be separate from ANT. ANT should be agnostic about it and
jakarta-ant should allow the rules of the "market-place" finally decide what
people like or not like to use. As long as ANT provides plugability, there
should be no reason for ANT to be in the bussiness of maintaining and/or
distributing XSLT, JPYTHON, or something else.

Jose Alberto


Mime
View raw message