Thanks for the overview, Nicola ! > Just to get you up to speed, the current issue is about multiple > inheritance, and how the current system allows cross-import (unwanted?) > side-effects, as Conor has brilliantly shown.
What I'm not sure I understand is what import has to do with multiple inheritance :-) Most of the problems with cross-import and side effects could be resolved by just using qualified names ( or namespaces ) - like java does to disambiguate imports. > A brief recap of decisions taken IIUC: > > - add an attribute to project: @importable=true, false, only I hope it is not required, and if it is missing it defaults to true. > - add possibility of prefix in import declaration > <import file="xxx" prefix="xxy"/> This would work as a "qualified name" ? What's the syntax for the prefixed targets/properties ? Any consideration on using XML namespaces for this ? > - all paths are resolved resolved to the importing file basedir The top-level importing file, or the imediate parent ? > - keep projectname.ant.file property for relative path resolutions Good. > - add <include/> task, like entity includes > - add <override-target/> task to override targets Is this "override-target" a substitute for <extends> and OO use of ant ( i.e. a buildfile == class, target==method ) ? If so, wouldn't be more intuitive to just use the real concept - i.e. extends and inheritance ? I know python has a very nice namespacing mechanism where you can replace or add methods dynamically to an object, but I don't know if this is desirable for ant. > Threads about import (in order): > 1 - ImportTask ant 1.6 > 2 - ant 1.5.4 : Import > 3 - override > > From thread 2 I wrote: > " > multi-import(import a,b) > target test depends=a.test, b.test > > a > target critical > target test depends=critical > > b > target critical > target test depends=critical > > > Here "critical" means a.critical to a and b.critical to b, but since > they reference a generic "critical", they get the only one that remains > after being redefined. The problem is that I did not redefine it in the > main buildfile! > " Can this be resolved by making all targets qualified after the build file is read ? That would mean ant will see: top: target top.test depends=a.test, b.test a target a.critical target a.test depdends a.critical b target b.critical target b.test depends=b.critical After reading any build.xml file, ant will just look at all targets and add the project name as a prefix if they don't have one already ( we just need to agree on the separator syntax ). When you look at a build.xml, all targets that don't have prefix are resolved to the current build file - it's pretty easy to understand. That mean you won't be able to use import for crazy overrding of some targets from one file with targets from other file - but if there is a real need for that i have no problem with a python-like mechanism where you can add/replace methods in an object at runtime. As long as it's not disguised as <import> :-) Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]