Mariano, I also agree with you and what you are saying. However I think we have several different parts of the proposal that are too loose and hence allow to break this general concept as you put it.
For example we have: 1) The jars containing the antlig code (which is defined by a classpath or classloader) 2) The URI for the antlib, which can be specified implicitely with an antlib:uri or explicitly with the uri parameter of typedef. Using typedef, you can load several antlibs to the same namespace and such. 3) antlib.xml file or resource which contains the XML definitions of the tasks and types. Now, all this things can be used in a systemetic way to achieve your goals (I think), but they can be used to act in a quite different way and bringing all kinds of problems. So, are our objectives just the suggested user patterns for ANTLIBs or are they mandatory behaviour of antlibs. Depending on what we want, it will change the way we teach people how to write effective reusable antlibs. As oppose to "only will work on my machine" kind of antlibs. This is what I do not think we have a clear understanding. How are people to use all this moving parts in a consistent way that promotes reusability, etc, etc. Jose Alberto > -----Original Message----- > From: Mariano Benitez [mailto:[EMAIL PROTECTED] > Sent: 17 May 2004 13:29 > To: Ant Developers List > Subject: Re: antlibs and classloaders #2 > > > > >This things sound like we are using the wrong abstraction here. > ><typedef/> inside an <antlib/> should use the antlib > classloader as the > >parent for any subsequent classloader. > > > >I do not see why that should cause an infinite recursion. > > > >I feel like we have a conceptual mismatch between antlib > "the jar" with > >the code, and antlib "the resource with the XML definitions". We are > >not treating them in a symetric way or as a unit. And hence > we are get > >into all this conflicting behaviour. > > > > > > I would like to pick from here and try to describe my > understanding of > the concepts. > > Antlib: I see this as a a definition of tasks within a namespace that > involves all the jars required to resolve the execution of > the tasks. To > put it plainly, I see it as the antlib.xml with a classpath. > So for me that defines completely the antlib and the > extra classpath > should be added to the antlib classpath. > > Also, for me is accidental that the antlibs should be > located in the > $ANT_HOME/lib or in a -lib <path>, actually the antlib > definition should > start from the antlib.xml, wherever it is, and then create a > classloader > based on the antlib definition. > > For the special case were the antlib jars are located in the base > ant classpath ($ANT_HOME/lib or -lib <path>) I would not > allow adding a > classpath since the antlib should be completely contained within the > base ant classpath, only when the antlib jars are outside I > would allow > defining an extra classpath. > > Also, defining antlibs in either way (being inside base ant > classpath or outside) should behave the same way, they should be > idempotent, meaning that once they are defined, they should not be > overriden, I understand that it is not wise to use the same uri for > different antlibs, the user should always try to pick unique > names for > the antlibs, otherwise we go back to a single namespace. > > This is my understanding of antlibs, it is probably out of synch with > what you envision on this, but I wanted to let you know what > I thought > antlibs were about. > > My 2 cents. > MAriano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
