On Wed, 23 Apr 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote:
> I am not even sure the code today was examining the value. 8-) It's been a long time, I know. > we probably should define more meaningful attributes > > ant-required-version, antlib-version (version used to buils > the library) > > that would probably mate things more clear. Fine with me. >> With that, do we really need separate <task> and <data-type> in >> <antlib> or are they just special cases of roles? > > They should be. So if they are just roles, why treat them in a different way than other roles? Why a <task> element? <define classname="..." name="..." role="task"/> could do the same and be more consistent. I don't have a strong feeling here, just trying to find my way through the ideas without having to read the code ;-) Maybe something could even be in different roles at the same time? See available, checksum or uptodate for things that are tasks and conditions in one. > Let me first say that this feature appeared by the need to be able > to say, > > <antlib name="A" classpathref="XYZ"/> > <antlib name="B" classpathref="XYZ"/> > > And being able to make sure that B and A use the same classLoader > and therefore they can use each other components. I understand that usecase and think it's important. See Steve Loughran's comment on the .NET tasks wanting to have access to the datatypes defined in the cpptasks project for example. > My solution at the time was this idea of a named classloader that > you could define using a classpath, and then tell your antlibs use > this or that classloader, if you use the same classloader visibility > is guaranteed. Take a look at what Costin had done to <taskdef> and <typedef> with the loaderref attribute. This has now (i.e. CVS HEAD) been generalized in ClasspathUtils, the infrastructure for named classloaders is there - at least the foundation for it. Stefan
