geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Proposed changes to plan elements related to classloaders.
Date Sat, 19 Nov 2005 00:11:02 GMT

On Nov 18, 2005, at 3:58 PM, Aaron Mulder wrote:

> This sounds great!
> Please further split out the data types so they're not all
> dependencyType (even though they all have URIs or maven chunks).
> Let's have one type where URI means a configID, and a separate type
> where URI means an index into the local repository.  Maybe they could
> just be called configIDType and repositoryEntryType.  Even if the
> contents are the same, they have different meanings and we can
> document them accordingly in the schema.

I'd be willing to change the type name to something more neutral, but 
not to duplicate it.  We can document the elements rather than the 
types.  Considering the likely future I'd rather leave it 
> Also, "parent" sounds pretty clear as to what it is, but "dependency"
> doesn't necessarily (isn't a parent kind of a dependency?).  It might
> be nice to try to think of a name to use instead of "dependency" that
> says "code to add to the classloader for the current module", like
> maybe "additional-jar"?

Dain has a plan that I hope he will explain soon that should make all 
of these elements identical in form, name, and function.  Dependency is 
what maven calls them and I don't see a strong reason to change their 

david jencks

> Thanks,
>     Aaron
> On 11/18/05, David Jencks <> wrote:
>> It's become apparent recently that some of the elements in our plans
>> related to classloading are a bit confusing.  In particular, there is
>> an include element that no one is sure what is for and is not used, 
>> and
>> a similarly named import element that is like the parentId, only 
>> better
>> :-).  Also the lists of special classes for the classloader are in
>> between the import and dependency elements.
>> I'd like to change the schema for all plans to use this:
>>      <xs:group name="classloader-infoGroup">
>>          <xs:sequence>
>>              <xs:element ref="sys:parent" minOccurs="0"
>> maxOccurs="unbounded"/>
>>              <!--            <xs:element name="include"
>> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
>>              <xs:element ref="sys:dependency" minOccurs="0"
>> maxOccurs="unbounded"/>
>>              <xs:element ref="sys:hidden-classes" minOccurs="0"
>> maxOccurs="unbounded"/>
>>              <xs:element ref="sys:non-overridable-classes" 
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>>          </xs:sequence>
>>      </xs:group>
>> The differences are that:
>> import is renamed parent.  This seems less confusing to me.  I can
>> support backwards compatibility in most plans, although perhaps not
>> plain gbean plans.
>> include is removed.
>> the class lists are moved to the end.  This makes more sense to me, in
>> that first we have the info on what goes into the current classloader
>> in the way of parents and contents, and then we have the modifications
>> to that list.
>> Comments?
>> thanks
>> david jencks

View raw message