ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phillip Lord <>
Subject Re: antmerge:- inheriting ant files.
Date Wed, 06 Aug 2003 14:59:33 GMT

>>>>> "Knut" == Wannheden, Knut <> writes:

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

  Knut> Neither is mine.  The solution I implemented is also specific
  Knut> to our environment and would have required some work to make
  Knut> it more generic.  But now that you've made something similar
  Knut> available, I don't see any need for me to do so anymore ;-)

True enough. 

  Knut> Thank you!

My pleasure. 

Actually although writing build support systems is not what I am paid
for, releasing software freely is, at the moment, what I am paid for
(sort of!), so I'm not being entirely altruistic. 

  Knut> Maybe, if you want, we could together try to incorporate some
  Knut> of my input into your work.  

I'd always be glad of improvements to antmerge. The "super" thing, for
instance, would be really nice to have, but is just not pressing
enough for me to code at the moment. 

  Knut> Hopefully all this will be superceeded by <import> some time,
  Knut> but until then it could prove useful.

Hopefully so. 

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

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

I guess this is true. The convenience, for me, though out weights the
difficulty. In Java, I think the problem is considerably less as the
type system will often pick this out. 

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

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

But it does seem mostly to work? This encourages me to try it. As I
say you can never really tell with heuristics. 

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

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

As properties can not be reset there would be a lot to say for them not
being procedural. By providing a standard ordering this is partly what
will result from antmerge. 


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message