ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: antmerge:- inheriting ant files.
Date Wed, 06 Aug 2003 14:23:58 GMT

>   Knut> Very similar to what I've done for our development environment
>   Knut> with a few minor differences:
> I figured someone must have done something similar, but I couldn't
> find anything on the web before I wrote this. Writing build utilities
> is not really what I am paid for!

Neither is mine.  The solution I implemented is also specific to our
environment and would have required some work to make it more generic.  But
now that you've made something similar available, I don't see any need for
me to do so anymore ;-)  Thank you!  Maybe, if you want, we could together
try to incorporate some of my input into your work.  Hopefully all this will
be superceeded by <import> some time, but until then it could prove useful.

>   Knut> o I have explicit top-level elements called <override-target>,
>   Knut> <override-property>, and <override-path>
>   Knut> o In the metioned top-level elements a child element <super>
>   Knut>    will be
>   Knut> replaced with the respective contents of the parent buildfile
>   Knut> o Attributes of the top-level elements are also inherited
>   Knut>    unless explicitly
>   Knut> overridden (e.g. <override-target name="compile" depends="">)
>   Knut> I don't know whether this makes any sense in your environment,
>   Knut> but I certainly found this to be a very flexible templating
>   Knut> mechanism. 
> I have certainly thought about something similar, although I have not
> got around to implementing it yet. I don't particularly want to use
> explicit top level elements (as I want people to be able to use ant
> support from their I use a DTD aware editor, and using the
> standard ant DTD is therefore a good thing!), but the lack of a
> "super" type functionality is a problem.

OK, that's a good reason for not using elements like <override-target>.  My
motivation for this partly stems from Java, where I don't like that
overriding is implicit.  Let's say you change the name of a target in the
parent buildfile.  All the sudden the corresponding target in the overriding
buildfile won't be overriding anymore, it will be added as a new target.
Usually this won't be what you want.

But a <super> and also having the attributes inherited is really nice to

>   Knut> Although it is a little bit disturbing that editing the
>   Knut> "build-in.xml" is pretty challenging, as you have to visualize
>   Knut> the eventually generated buildfile in your mind.
> Antmerge has a standard set of rules for generating the build file
> which generally "do the right thing". There are cases where they do
> not. Most of these are due to ordering of the end build file. Its a
> little hard to explain, so just trust me. 
> I think I can get around it with some sorting of the end build.xml
> file based on top level tag. So all the "property" tags will come
> first, then all the path like structures next, and finally all the
> targets. How well this will work in practice, I don't know. Sometimes
> these heuristics sound great, and work badly. And sometimes the
> opposite. 

I know exactly what you're talking about.  Incidentally I solved it the same
way: <property> tasks in the overriding buildfile get added to the top of
the generated buildfile.  But it isn't really satisfactory, as it isn't very
transparent for the buildfile maintainer.

> It's interesting actually. I notice that ant may be getting an
> "import" task (its in the CVS). I think that they will have some of
> the same problems as me. Parts of ant are procedural (properties,
> paths), and parts are not (targets).

That is exactly the problem!  I guess properties and paths wouldn't have to
be procedural, but that's the way it is.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message