ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Configure->Template->Build
Date Thu, 31 May 2001 11:26:50 GMT
At 11:08 AM 5/31/01 +0100, Jose Alberto Fernandez wrote:
>> 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.

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

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. 

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

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.

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

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

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

keep thinking - thats just the tip of it. Think project references, sharing
and being first declared type etc. Now do you see the complexities or
should I go on ? ;)

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

So your response is: Ant shouldn't allow medium to large maintainable
projects. Not a tenable position in my opinion ;)

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

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

not relevent at all to discussion? I am quite aware of ant as a task engine
- remember it was me who was pushing that perception for ages ;)

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

Thats because you are mixing templating in with configuration again.
Configuration is just what you describe it. Templating is taking a project
"template" and fitting it to a particualr project "instance". The template
stage comes after configuration stage (and must to get values from it).



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

View raw message