> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Wed, 23 Apr 2003, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> >> 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 ;-)
>
I think you can already. The <task> and <datatype>(sp?) is just neat
syntax sugar. As mentioned in a previous message from Antoine:
Once you define a new role 'myrole' you can say:
<myrole classname="..." name="..."/>
so tasks and datatypes are just predefined roles.
> Maybe something could even be in different roles at the same time?
No problem, declare the class in as many roles as you like.
> See available, checksum or uptodate for things that are tasks and
> conditions in one.
>
Yeap.
> > 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.
>
If this is already suported by the core, then scrap what I have and replace it
with the way the core supports it. I have no objection. After that we can
comeback
begging for any additional features we needed and everybody will get them.
Jose Alberto
