ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: antlib
Date Wed, 23 Apr 2003 15:50:40 GMT
> From: Stefan Bodewig []
> On Wed, 23 Apr 2003, Jose Alberto Fernandez
> <> 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.


> > 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

View raw message