xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Calahan <p...@bea.com>
Subject RE: code to contribute: JAM
Date Thu, 25 Sep 2003 17:54:10 GMT
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)
>or
>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.

-p




>David
>
>
>----- Original Message -----
>From: "David Remy" <dremy@bea.com>
>To: <xmlbeans-dev@xml.apache.org>
>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
>this?
>
>-----Original Message-----
>From: Patrick Calahan [mailto:pcal@bea.com]
>Sent: Wednesday, September 24, 2003 5:24 PM
>To: xmlbeans-dev@xml.apache.org
>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
>   inheritance.
>
>
>-p
>
>- ---------------------------------------------------------------------
>To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
>Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
>
>
>
>- ---------------------------------------------------------------------
>To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
>Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/

Mime
View raw message