ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Tue, 01 Jan 2002 15:22:48 GMT
So, if I understand you correctly, your only issue with the inheritance pattern
in what respects to classloaders. Am I correct?
I thought you were refering to some other issue related to the API. What a releave :-)

To me this problem is orthogonal, and it definetly needs to be tackled as part of our library

I see two scenarios here:

1) We need access to the code, really do not care about Classloader equality.
This I think is the most common case. Here we just need to be able to say "when loading
this tasklib put this or that jar in the classpath". Wheather one says this internally (using
Class-Path on the tasklib jar, for example) or externally via <classpath> element in
tasklib usage, are possible solutions. The former seem easy to use, but since jar names get
embedded on JAR files it can be a nightmare for administration when multiple versions of libraries
start to show  up. And different 3rd party libs require different versions of other 3rd party

2) We really care about classloaders. This is the case when for example a tasklib task requires
access to a <datatype> defined on another tasklib. If the classloader use for the DT
are not the same, the code will not be able to recognize it. For that we need to actually
be able to identify a particular Classloader instance (using perhaps a ref) and be able to
tell when loading the tasklib to use or "extend" (to get my point) the other tasklib classloader.
I can see doing this in two ways:
(a) by being able to put references to particular Classloaders, maybe as a side effect of
the <classpath> datatype or by having a <classloader> DT of its own:

    <classloader id="cl2"  extends="cl1">
        <classpath refid="myAdditionalClasses" />

this is powerful but seems to be a little too low level.

(b) Make this composition part of the tasklib declaration, something like:

    <tasklib id="tlib1" ....../>

    <tasklib id="tlib2" extends="tlib1" ...... />

Which will use as the parent classloader for tlib2, that used for tlib1. Here people manipulate
tasklibs abstractions which seem to be much more high level and easy to understand.

BTW, I have no idea about the current syntax for tasklib declarations, although I still think
<antlib> is a better name ;-) in particular since libraries will contain much more than
just <task>s.

Jose Alberto

----- Original Message ----- 
From: "Kerns, Bob" <>
To: "'Ant Developers List'" <>
Sent: Monday, December 31, 2001 7:18 PM
Subject: RE: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types

> Doesn't "very hard" overstate the case substantially? As with EJB's, etc.,
> using the Class-Path: attribute in the Jar manifest should provide the
> mechanism for using classes from another tasklib, including via inheritance.
> (Although the design of the classloader that loads them may affect whether
> they share the actual same class, or another copy).
> There are arguments both ways for or against using inheritance, but I agree,
> it shouldn't be lost.
> -----Original Message-----
> From: Jose Alberto Fernandez []
> Sent: Monday, December 31, 2001 8:03 AM
> To: Ant Developers List
> Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
> From: "Peter Donald" <>
> > 
> > In the architecture we have discussed for Ant2 it will be very difficult
> to 
> > subclass tasks unless they are in the same tasklib. So if there is
> behaviour 
> > that needs to be shared it should be refactored into another bean and 
> > delegated to. In the rare cases that do need inheritance it is expected
> that 
> > you don't mess things up ;)
> > 
> This sounds like a very large limitation to me. If you look at all the
> war/jar/ejb/etc
> tasks they just subclass and add new attributes or elements or whatever.
> This things should not be in the same tasklib because some are core while
> others are optional (for example).
> Inheritance is well known and valid pattern and I think we need to make an
> effort not
> to loose it in the design.
> > No idea if base classes TaskInfo will add to or be replaced by subclasses 
> > TaskInfo.
> Jose Alberto
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message