Hi Stefan,
> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> > looks like that
> > <antlib version="1.5" >
>
> Is that the version of the antlib parser, i.e. does version define the
> format of the file? The minimal version of Ant the antlib needs? Or
> is that the version of the antlib itself? I think we'll have to
> provide all three items, while the first two may in fact be just one.
This are things we need to define. I am not even sure the code today
was examining the value. 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.
>
> > 2) type definitions
> > --------------------------
> >
> > allowing to define new implementations of mappers, selectors, paths,
> > conditions,
>
> We definitely need this, roles may be the key here. With that, do we
> really need separate <task> and <data-type> in <antlib> or are they
> just special cases of roles?
>
They should be. We need to tae care of how BC works in here. In the old days
we had all those issues about outside tasks and inside tasks, but today
with the new ProjectHelper implementations we probably can standarized much
easier.
> > 4) A framework for managing classloaders where you can specify which
> > classloader to use when loading an antlib.
>
> This is the hardest part IMHO. Sorry, I haven't looked at the
> proposal thoroughly so far. Is there such a classloading framework in
> place? What does it provide and how do you use it?
>
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. (Tis also means antlibs do not need to be in
the classpath to be able to share).
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.
Not the method may be too crude, I do not mind having something better or more
suttle
or more general (we know we define classpaths all over in our build and we are
never
able to share a thing). At the end of the day the requirement is: two antlibs
not
in the java classpath but using the same ANT classpath definition should be
able to use
each others components.
All ideas wellcome,
Jose Alberto
