> From: Peter Donald [mailto:[EMAIL PROTECTED] > > At 11:44 AM 6/1/01 +0100, Jose Alberto Fernandez wrote: > >> From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > >> > >> > Flat is theoretically the best example because all > definitions are > >> > local. However I guess I am worried about usability. > >> > >> What if you'd allow to import types from a nested > namespace into the > >> default namespace? Something that is what you call flat > with a little > >> bit of global added to it? > >> > > > >We could have something like: > > > > <projectref name="mod" ... /> > > <taskdef name="blah" aliasfor="mod->foobar" /> > >or > > <import name="libblah" lib="mod->modlib" /> > > > >I do not think we can just use them without redeclaration, > unless we use a > >different namespace operator: > > > > <mod->foobar ..... /> <!-- This is illegal syntax --> > > <mod:foobar .... /> <!-- I think this is fine XML --> > > > >comments? > > Personally I get kinda scared when there is talk of sharing type defs > between projects in this manner. Where do you see it as > useful? I can see > it as useful when propogated via antcalls (ie > subordinate/child projects) > but become concerned when peer projects (via projectref) are > using it. >
The question for me is how reusable do we want the information in the "peer" projects to be. In one extreme, if we want it to behave like "include" (not that I am advocating anything) it will require for the including project to have access to anything available in the included project. Because it is like a macro expansion. Now, we are not doing "imports" exactly (thank God) so the rules are more fuzzy. What we habe been talking is that <projectref> loads an instantiation of the project (given the <param>s passed in the declaration). You can access anything in the namesapace, any properties AND any IDed type instances. If you can access the instantiated values of a type, then it seems to be a logical consequence that you may need to have access to the type itself. For <tasks> one may have a simillar argument. If you have access to the targets in the instantiated project, you may also want to have access to the tasks defined in there. For example a projectref may define a group of libraries that are used for performing its work. The tasks may be interdependent in the sense of compatibility between version or what have you. I would think, one may want all this things said in just one place, for maintainability reasons. The referring projects will just use the consistent by just indirecting on the projectref namespace. > Personally I would prefer namespace resolution for types (and > aspects) to > be static "type" information rather than dynamic "instance" > information. So > namespace of type would refer to the library it was exported > from (or a > user assigned value). > But if you look at <projectref> as static. It is not a task, it is simillar to <taskdef> but for projects. I know that there is certain dynamic behavior for <taskdef> and such, but in principle it is defining a static thing that cannot once defined. > Can anyone give a good usecase forsharing type defs between > peer projects? > Does anyone has a good example on when one may need a new type definition? The predefined ones have been sufficient for me. I would need something like that first, to be able to come up with an example. ;-) Jose Alberto
