Nicola Ken Barozzi wrote:
>>> Every JAR in $ANT_HOME/lib would be scanned for a descriptor in >>> META-INF (for example; be it some XML format or a properties file), >>> and that descriptor would contain a URI that needs to be used as XML >>> namespace URI in the build file. >>> >>> Hope I'm not totally off here... haven't followed much of the >>> discussion before this thread. >>> >> >> No, spot on - that is what I had in mind. 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
