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
dependencyType.
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
name.
thanks
david jencks
Thanks,
Aaron
On 11/18/05, David Jencks <[EMAIL PROTECTED]> 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
