text: Nicola Ken Barozzi.
  That's what I had in mind too ( or close enough :-).
  I was just describing it in reverse - you look in build.xml, see a
  namespace URI ( or an <antlib name=> ) and you locate the descriptor
  using a resource derived from the URI.
  JSP are similar - you need to declare all taglibs that you use in
  the jsp page. Same for XSLT - where all extension elements/functions
  you use must be declared.
  One important issue - if you don't have the antlib, you obviously
  don't have the descriptor either. So the info about where to download
  must be derived from the URI - either using an indirect catalog or
  just using the URI as a base for lookup.
  We can have the URI carry both informations ( descriptor location
  in the jar and URL for download ) - just use an encoded form of the
  URL as the resource path.
  > I think too that this is the way, just with a change:
  >
  > - Automatic antlib loads in ant.home/lib would be without namespace,
  > as they are treated as "default" ones.
  I think both Conor and me are disagreeing with you on this one.
  XSLT, JSP, etc are all requiring some explicit information about what
  antlibs you need - otherwise a user who doesn't have the jars in ant/lib
  will have no way to guess what is wrong and what .jar he has to install.
  > - Normal taskdef would be without namespace.
  I.e backward compat - that's clear. If you mean: you should be able to use
  taskdef for antlibs - I agree.
  > - <antlib> call would be with namespace.
  Unless <taskdef> is used to load the antlib - which will work like it does
  today.
  > As for a descriptor, being a Cocoon developer, and having used xml for
  > so much time, I can only suggest... not to use it, simple properties
  > like now is just good enough, just add a namespace property as suggested
  > above. :-)
  I agree - keep the simple properties for the simple case ( i.e. what we
  need today ), and eventually use an XML descriptor for advanced features.
  Costin
  --
  To unsubscribe, e-mail: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
  For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>