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 12:38:03 GMT
> From: Peter Donald []
> At 11:08 AM 5/31/01 +0100, Jose Alberto Fernandez wrote:
> >
> >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
> >JavaScript? That really bothers me.
> The only other alternative is making ant a complete scripting
> language. If
> you can think of another alternative then I am all ears.
> However as yet you
> have failed to provide an alternative ;)

I thought I did.

> >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.
> ouch - lets wave good bye to maintainability and modularity then ;)
> >> 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?
> You ever programmed assembler? If you have then you have
> probably had fun
> writing self-modifying code. Once you "get" how to do it - it becomes
> simple. But any mere mortal who stumbles across code
> (especially if you
> include implicit assumptions about architecture - yay for
> address wraps and
> relocs ;]).
> This is essentially what you are proposing. Writing a task
> that modifys
> build process and then running this generated file, right?
> Same principle.

Well, since the task is not modifying the build file that it calling the
task itself, I have no idea why are you talking about self-modifying code.
Moreover, your proposal is doing in escence exactly the same thing, so I
fail to see what is the hoopala about it.
Just because I generate a file on disk, and you just generate the file in
memory does not make much of a difference.

> Generating input for the current process is a painful think
> to maintain and
> debug. About the only people that still use it nowadays is
> the lispers. But
> then again even lispers don't generally do it except to create dynamic
> command lists (which is usually dealth with via interfaces,
> registries and
> factories in modern environments).
> Hiding this complexity from the user is soooo much better.

What re you hiding, you are asking them to generate code in the form of an
ANT XMLDOM (or something to that effect), my task is just writing that into
a file. None of us is hidding anything.

> >> ><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>.
> sure there is. For DAG and property resolution.
> >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
> >there.
> That is appropriate to both uses (ie projectref as a ref and
> as a "target
> library"). All I see you using projectref as is as a xsl:include with
> candied syntax - something I don't see any point in doing.

It is not XML include. I am trying to move away from includes since I think
they are the wrong abstraction to have. The differences are:

(1) modularity, based on separate name spaces. This is a major point.
Includes require you to avoid name collisions because everything is in the
same namespace. It means you need to be aware of every property used on
every include or you can have all kinds of extrange behaviours (very common
problem in MAKE).

(2) instantiation, based on parameters. The values assigned to properties on
each instance can depend on the parameters you pass, which means that you
can adapt the way the rules work, based on just a few parameters. More over,
you can have multiple instances of the same project doing different things
depending on the particular instantiation (you can never do that with

(3) integration, based on name acccessability. As oppose to <ant> or
<antcall> here you have access to the properties defined in the other
modules and you also have access to the DAG by being able to name their
targets. This is the only one you get with include.

> >We just have to use them in the correct way :-)
> personally I see this causing much pain with little gain. If
> you recall I
> have said that I think "include" is error prone, painful to
> maintain and
> ugly way to gain extensibility. Anyone who has worked with

I agree with you here. "include" is bad. But for the reasons I gave above, I
think <projectref> can be shapped into something much better than include.
As I said, it can be seen as a way to organize different aspects of a build
into libraries. I do not see them to be nither painful to use, nor painful
to implement (given the right datastructures) and they can give you a lot in
terms of modularity. I do not think we have them just right, yet. There will
be issues to be solved. 8-)

> something like
> php knows what I mean ;) Fast dev time, great for small
> projects but scales
> poorly. Thats why most recent dev toolkits are moving away
> from that and
> towards things that have single pages (or templates) that host
> "components". Components are far more maintainable and the system as a
> whole is far more extensible. (Give me Velocity/WebMacro + Bean suite
> anyday over xsp/jsp/php/asp/etc for anything but small/medium sites).
> Considering that projectref will likely be used in more
> advanced/larger
> projects it seems logical that we should be going for more
> maintainable
> solution.

I could say the same thing about asking people to write JPython or
JavaScript ;-/

> >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.
> If you want these sort of hacks you have include,
> anton/javaon etc which I
> believe will fill all your needs. It is far better to make projectref
> actually be a project reference rather than a library of
> targets. Keep it
> separate from templating so we can build maintainable projects.

What I propose are HACKS while yours are .... interesting way to approach a

> >
> >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.
> So your response is: Ant shouldn't allow medium to large maintainable
> projects. Not a tenable position in my opinion ;)

No, my response is that may be the way to structure it with ANT is

> >Yeap, ANT's aim for people to say what they want done, it is
> not designed
> >for the system to "discover" what to do.
> Straw man arguement - who said it would?

How is your configure suppose to know if rmic is needed or not on a
particular module. For what I understand, your script will somehow find this
out and adds that target in there. Isn't that what you want to do? Same for
javacc, etc, etc.

Jose Alberto

View raw message