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 model.
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
libs.
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" />
</classloader>
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" <[EMAIL PROTECTED]>
To: "'Ant Developers List'" <[EMAIL PROTECTED]>
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 [mailto:[EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]>
> >
> > 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: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
