I've done some more historical research and now want to keep the
include element and am inclined to keep the import element with its
current name. Discussion inline.
On Nov 18, 2005, at 3:35 PM, 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>
Now I want:
<xs:group name="classloader-infoGroup">
<xs:sequence>
<xs:element ref="sys:import" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="include" type="sys:dependencyType"
minOccurs="0" maxOccurs="unbounded"/> <!-- this should be a ref also
-->
<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.
Reasons for keeping import:
1. We have already put out M5 using import, and I remember promising
that we wouldn't change the xml incompatibly.
2. Apparently the term import is used by osgi for a similar purpose.
include is removed.
Reasons for keeping include:
What include does is to copy the contents of the dependency into the
car file. This is not particularly useful for server side
configurations that depend on other configurations, and really need a
repository. However, its really intended for building small executable
jars that include everything they need to run. For instance the
shutdown jar would be an ideal candidate for this. We can include as
much kernel, gbeans, etc as we need and still fit it all into a single
jar that can be moved around away from the repo and still work without
reliance on fragile mechanisms such as manifest classpath.
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.
I still want to do this.
thanks
david jencks
Comments?
thanks
david jencks
