ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Configure->Template->Build
Date Wed, 30 May 2001 15:31:03 GMT
At 02:49 PM 5/30/01 +0100, Jose Alberto Fernandez wrote:
>Peter,
>
>This is a very interest discussion, in my opinion, I think my views has
>evolved, if not changed ;-), as we have gone along. So here is how I stand
>at this time:

Don't worry a while back I was 100% behind dynamic templating until someone
came along and basically said "you are all wrong - dynamic templating is
evil". I did a 100% about turn within about a minute after reading the
email ;)

>- I continue to believe that ANT usage patterns, in general, do not require
>the usage of a configuration stage. I think we agree on that as you state
>that only very sophisticated users will require such feature.

at this time. In the future with introduction of more mature java dev
environment/processes (ie directory layout and distribution format) I
believe most users will use it. But it is not here now (and probably won't
be till sometime next year at earliest).

>- I actually have entrench(sp?) more in thinking that ANT's core, does not
>need to be rearchitected to support a configuration stage. It may need to be
>redesign to support other stuff, but not a configuration stage. This is a
>change from before.

Right - thats is fine until you realize the results of templating require
configure stage having been run before hand. If you recall a while back I
was advocating we ignore configure until ant3 but when I tried to build
some practical examples of medium sized complexity I realized that you need
configuration for templating to be useful (and I would prefer the user not
have to manually construct property files themselves).

>- The reason for the above, is that I now think your requirements can be
>fulfilled by an optional task which can execute whatever software, this
>sophisticated group wants, to generate their configured build files. I have
>never being oppose to that since such task (or tasks) would be just a
>regular task with no special behaviour with respect to ANT core. The
>language, syntax and semantics for such a task are irrelevant from ANT's
>point of view the same way ANTs do not care about what the <javacc> task
>does or generates.

Right - this is partially what projects like alexandria+gump do at the
moment and how I layout some of my own tests. I found it a maintanence
nightmare.

>> >Something like this, looks that can solve quite cleanly the
>> issue of the 17
>> >identical buildfiles.
>>
>> If they were identical yes but they keys is *mostly*
>> identical. It is the
>> slight variations between them that becomes painful (besides
>> which this
>> layout assumes java is immature - hopefully that will soon
>> not be the case).
>>
>> Because they have slight variations you end up with hariy
>> build files or
>> else use per task if attributes or implement an if task (like what was
>> described recetly).
>>
>
><projectref> is just like instantiating a library of targets. 

Thats the first time I heard it described as such. From my impression it
was separate self-contained build files (and that is how the proposals
currently implement it). 

>You can still
>put on each one of the 17 buildfiles additional targets containing the
>things that are different (those small things) and make the refered project
>have dependencies on those targets. Without that I  think the whole idea of
><projectref> would be useless. So I expect the ability to do such things as
>part of the final design for <projectref> in ANT2.

I was under the impression that projectref was a formalization of cross
project building and interaction. The use case that was originally proposed
was the catalina project. It actually has 3 (or 4???) projects
contained/interacted from the same CVS. They have the webserver, naming,
jasper, servletapi etc. The original use case was to allow them all clean
interaction and management of cross-project builds. (antcall fails as it
does not manage the DAG).

The X-Project DAG would be broken if used in the way you suggest unless we
allowed the same project to be reffed multiple times under different
aliases and had some other hackery. This is of course not the most simple
thing (not even the same zone as simple).

>I think we are both advocating the same, is just a question of the thickness
>of the slice. ;-)

Possibly but remember that you can always merge together layers if
separation is artificial but you can never break apart layers once you
release a project. (Or you can try to - but it is hell to maintain). So if
you go with separate stages and they end up being useless they can always
be shaved but starting with 1 layer you can't remove functionality from it
without pissing off a whole bunch of people ;)

>Of course the problem is what do we mean by "variations". Are we talking
>about properties being set differently? 

maybe - not relevent though.

>Are we talking about them executing different sets of tasks altoguether? 

yep - in many cases. For instance in many projects you will have a compile
target. In this you will do things like depends, javacc, javac, rmic, copy
properties files from java tree etc.

Some projects don't need rmic so they shouldn't run it, others don't need
javac etc. However if present have to be done in specific place. The way
you are forced to do this now is break up the one "compile" target into
three targets (before-rmic, after rmic and rmic targets). You can also end
up with two extra targets to do property detection and setting. Many of
these targets have if or unless attributes.

Now add the complexity that compile may have more than 1 "optional" task.
You can endup with a plethora of targets that are essentially workarounds
for ant modle not being "rich" enough. To a somewhat unrealistic extreme
you cou could end up having one task per target.

These things are unmaintainable nightmares (do a test run in ant1 to see
what I mean). You may have kept ants core "clean" but every
semi-sophisticated build file will be an utter mess.

>Is it some other bizzare combination? I
>am asking for a real world example so that we can stop the what-if game,
>which is a never ending game.
>
>> This does mean dealing with different locations of tools/jars. ie
>> /usr/local/java/* for linux systems, /opt/java/* for some
>> other unixes,
>> /opt/* for other unixes and presumably a java standard for
>> other platforms
>> will eventually evolve. With tools like jjan/cjan on the
>> horizon this is
>> becoming more of an issue.
>>
>
>I still do not know how your scripting will deal with this issues. It looks
>like you would need to provide a whole accompaning library of function that
>provide OS independent means of finding this things out, just like the m4
>libraries used by autoconfig. But hey if it is in an optional task, it is up
>to the maintainers of it. ;-)

Most of standard tests will be in form of pseudo tasks (more on this later)
but in cases where you need adhockery you can go straigh to use a
supercharged scripting language of your choice.


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