Jose Alberto Fernandez wrote: > One of the problems I have with the "rewriting" approach is that target > names get rewritten y the caller which means that two independent > importers may decide to use the same prefix and hence you get a clash. > Namespaces or java-style fully-qualified-names are a property intrinsic > of the imported file, that is the reason that makes it safe.
That's why I think it's better to not try to be too flexible in allowing arbitrary rewriting, but do it in a canonical way: - after a build.xml is read, all un-qualified names get prefixed with the project name and a delimiter ( need some tricks for ant-call, but it's possible ) - you can call a target by the local name as long as it is unique, otherwise you need qualified names. No overloading, no conflicts, no abiguity. > Single inheritance (a la Java) requires having syntax that allows for > extending only once, something like: > > <project name="q" extends="this/other/build.xml">...</project> > > if you use something like a task to specify the extend then you may write > multiple inheritance and all these ambiguities appear. > Could we live with single inheritance and <include/> instead of <import/>? My point is that <import> is different than "extneds". > The escenario is that you have your tipical: > > a > target compile depends=precompile > target precompile (do-nothing) > > b > target precopile (very complex precompile lib) > > build: > import (a,b) > > With cross-talk that is all you need to connect the two > and get the required effect. Without cross-talk you would need to add > more targets to build: With qnames there is no crosstalk. a target a::compile depends a::precompile target a::precompile b target b::precompile build: import a, b You can call a::compile ( which will call a::precompile ), etc. > target precompile depends=b.precompile > > or > > override-target compile depends=b.precompile, super.compile Too complicated IMO. All import should do is load some build files and deal with the name conflicts in a clear way, without becoming a very hacky solution that nobody understand - and to be honest I have a lot of trouble understanding most of the overriding - even in the simple examples on the thread, I can't imagine what will happen when people start using this with dozens of targets. Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
