Some comments on the issues inside: > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] > > Costin Manolache wrote, On 07/08/2003 4.43: > > >>- add possibility of prefix in import declaration > >> <import file="xxx" prefix="xxy"/> > > > > This would work as a "qualified name" ? > > I think basically yes, but > > > What's the syntax for the > > prefixed targets/properties ? > > prefix+targetname > > example: > prefix="a" > name="b" > result="ab" >
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. > >>- 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 ) ? > > In a sense yes, but not quite. Import does not fully encapsulate the > calling buildfile. @see XSLT include and import for a more > similar concept. > > > If so, wouldn't be more intuitive to just use the real > concept - i.e. > > extends and inheritance ? > > Dunno. > 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/>? > >> 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 ? > > This is what Conor seems to propose IIUC, and what others are > not keen > on, and instead talk more about the xslt-type import. > See my comments above about target rewriting. > Just remember that we are not talking about renaming properties, or > resolving basedirs, so it's not full encapsulation, but just > dependency-shielding. > > I have not yet made up my mind, but it seems that ATM there > is a reason > favor some kind of "namespacing" because I see more harm than good in > side-effects that come out of not doing it. How this can > still solve my > usecase is yet to be seen. > > > 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 ). > > Or simply use the proposed prefix when importing. > > > 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> :-) > > Well, IMHO I personally don't see a real, strong, compelling > reason to > have targets have crosstalk between themselves, but I do have > an equally > strong need to import dependencies. > 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: target precompile depends=b.precompile or override-target compile depends=b.precompile, super.compile the question is how convinient is to have to thread all this interconnections by hand on the importing buildfile. > As I have outlined before, imagine I import a file that has a compile > and test targets. > > target compile > target test depends=compile > > I want to be able to do "ant compile" and have it compile. Thus the > compile target should not be renamed. > > Then when I want to insert a pre-condition to the compile > target, I want > to be able to redefine the compile target. > Reusing it in a differently-renamed target is not ok, as when I call > "test", it will not have a dependency to the new version of > the target. > > So > target compile > target newcompile (call:prestuff, compile, poststuff) > target test depends=compile > > If I call newcompile, it works but calling test will not call the new > one, thus making it impossible for me to *decorate* the > compile target, > thus specializing the template. > > So I should have: > target compile -> original compile > override-target compile (call:prestuff, original.compile, poststuff) > target test depends=compile > > Till I import *one* compile target instance, all is well. As > soon as I > have more of them, I start having problems. > > The question is: after a multiple import, which compile > target becomes > the "default" one, ie the one without renaming? > In XSLT-inheritance, the last one imported will win. In programming inheritance, this is an error due to ambiguity, the only way to resolve it is for you to override the target and explicitly indicate what should be done. > Second question: how do we deal with the fact that targets > that are not > even used have crosstalk between themselves? > > And most of all: how to solve the last two points while keeping it > possible for me to retain the use-cases? > > As you see, for this usecase, <include> is not strong enough, as I > cannot override, and complete namespacing prevents me from overriding > the dependency chain. > Actually, <include/> will not allow you to have separate includes with the same target, since it means literal inclusion. Nevermind overriding. I thought at one point that <include/> and <override-target/> could be enough, but I do not think it is. :-( Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
