On Wed, 8 May 2002 22:12, Darrell DeBoer wrote: > > > 1) Types/TypeLibs can be registered under a namespace, which *may* be > > > taken from the AntlibDescriptor (say, an AntLib name attribute), but > > > can also be specified in other ways (eg <typelib library="ant1compat" > > > namespace="ant1"/>) > > > > I would prefer it to be based on the name of the antlib (ie internal name > > specified in manifest). I suppose we could support aliasing but I would > > like the importing to be very obvious that it is aliasing that is > > occuring. Maybe something like > > > > <typelib library="ant1compat" namespace-alias="ant1"/> > > This is (almost) exactly how it now works: > <typelib library="ant1compat" namespace="ant1"/> > > Maybe we can default to use the antlib name if available, where namespace > isn't specified.
Definitely. <typelib library="somelib"/> should work pretty much like on-demand imports in Java (ie, import somepackage.*), so that each type is available by fqn, and by short name if unambiguous. > Me too - and that's how it is. As long as we're aware that this means that > Type names cannot include '.'. And a bunch of other characters - we should run the type and role names through a really strict NameValidator, eg, letters and digits only. > Converter classname is munged in the > ConverterDefinition into a type name. (SInce converter names are never > exposed it doesn't really matter what they look like internally) Well, not entirely. You need to know the name when importing an individual converter from an antlib: <typelib library=".." role="converter" name=".."/>. Not a big deal, the munged name is probably fine there. -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
