ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Configure->Template->Build
Date Thu, 31 May 2001 10:08:56 GMT
> From: Peter Donald []
> At 02:49 PM 5/30/01 +0100, Jose Alberto Fernandez wrote:
> >- 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).

Well, this to me is bad. As I was saying originally, if regular users are
going to finish writing JPYTHON or JavaScript or whatever instead of ANT,
then I have a problem. The same problem I have with autoconfig BTW. What use
is Antidote and other visual ANT tools if users are writing JPYTHON or
JavaScript? That really bothers me.

> >- 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).

I am proposing that your configure task will generate an ANT file which is
then executed using <ant> such a call, as a matter of principle, needs to
execute any templating or whatever stages we say calling ANT are suppose to
do. So I see no issue here.

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

What is nighmarish about it. Why is it nighmarish for this but not for other
tasks that generate things. Can you explain?

> >> >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).

If you read my comments in that subject I am asking for exacly this things.
Otherwise there is no reason for naming the <projectref>. They are they own
project but they are able to interact with others by the "X->Y" operators.
Since "X" is the local name in the caller, you have all the pieces right

We just have to use them in the correct way :-)

> >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).

Since I do not know about Catalina specifically, I do not take the example
to be just for  solving the "Catalina issues" I definetly want some much
more broad in scope.

> 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).

This is not difficult. It just requires a correct definition of symbol
tables. Just like in any other programming language with nested scopes.

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

Humm, this reminds me of some of the MAKE based building environments. I do
not think ANT was designed with that kind of predefined building
architecture in mind. In part because the aim has been at providing tasks
powerfull and simple to use so that you do not need such sheltered
predefined environments.

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

Yeap, ANT's aim for people to say what they want done, it is not designed
for the system to "discover" what to do. Notice that it is upto the tasks to
decide whether they actually need to do something or not. This is a major
difference when you compare with a system like MAKE. In the case of MAKE, it
is MAKE that decides what to do or not to do, not the "tasks" it executes.

So, I think there is certain mismatch between what you are trying to do with
ANT and what ANT was designed to do. I don't know if I would call that
"configuration". To me configuration in the sense of build systems has to do
with adapting the build process to a certain execution environment (like a
particular OS, processor type, etc.) but what you are talking about is
adapting a build process-model to the needs of a particular project.

That does not sound like configuration to me.

Jose Alberto

View raw message