At 11:12 AM 9/25/2003 -0400, David Bau wrote:
Rather than working privately with Patrick, I think he should get a CLA
faxed in and get the code checked in, and then work here in this forum to

Ok, this is done.

Patrick, depending on the # of files, a reasonable package to check things
into v2 might be

org.apache.xmlbeans.impl.jam (if we think it's going to be largish)
org.apache.xmlbeans.impl.common (if we think it's going to be smallish)

The public face of it consists of about 15 interfaces, so I think it will need its own package.



----- Original Message -----
From: "David Remy" <>
To: <>
Sent: Wednesday, September 24, 2003 9:37 PM
Subject: [xmlbeans-dev] RE: code to contribute: JAM

I think this code could be valuable to v2.  Perhaps it should be checked
into the v2 directory, or a sandbox directory, so that we can look at the
code, and see how it would work in an xmlbeans v2 java -> xml scenario?  If
that makes sense, David, would you be the one to work with Patrick to do

-----Original Message-----
From: Patrick Calahan []
Sent: Wednesday, September 24, 2003 5:24 PM
Subject: code to contribute: JAM

Hello all.  I have written a package I would like to contribute to xbeans
v2.  It is an abstraction layer for Java types and their associated metadta
that I believe will be critical in xbeans' compilation phase.  Just as you
need a SOM to represent the schema types you are binding to and from, you
use JAM to model the Java types you are binding to and from.

Here is a blurb from the package.html docs that provides a little
more detail:

The Java Abstraction Model (JAM) provides a representation of
Java abstractions (such as classes and methods) and their
associated metadata.  This model serves to decouple its clients' code
from any specific introspection mechanism such as javadoc or reflection.

This approach has several advantages:

  A unified API for viewing Java types
    Java types can be described in java sources, in class files,
  or even synthesized from scratch.  JAM provides a single API which
  allows your code to remain decoupled from tool such as reflection
  and javadoc.

  Clean and consistent access to metadata
    Metadata is a hot topic at the moment, and the way we deal with it
  is going to change dramatically over the next year or two.
  By writing to the JAM API, you can be sure that you won't
  have to rewrite your code to accommodate emerging tools and
  standards (JSR175, for example).

  Pluggable metadata stores
    Metadata can be retrieved from an external source (such as an XML file)
  or even generated programmatically.  This also allows metadata to
  be associated with Java constructs that may not normally support
  annotations (such as packages).

  A Node-based view of Java constructs
    JAM clients have the option of viewing their java constructs as a tree
  of generic, DOM-like nodes (packages contain classes, classes contain
  methods) each of which may have associated annotations.  This is
  extremely helpful for tools which wish to support annotation


- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
Apache XMLBeans Project -- URL:

- ---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
Apache XMLBeans Project -- URL: