incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cliff Schmidt" <>
Subject RE: Proposal: XMLBeans
Date Thu, 03 Jul 2003 19:02:28 GMT
(copying the other lists, by request)

Thanks for all the good questions and advice, Howard.  Please let me know
if the following leaves you with other questions or concerns.

On Wednesday, July 02, 2003 7:26 PM, Howard M. Lewis Ship wrote:

>> See [ BEA's
>> quick start page] for more information.
> There's a commons module, Betwixt, that very much overlaps what you
> describe here.  

The main difference is the XML Schema support.  However, there are
areas of XMLBeans that overlap with other projects (especially commons 
modules like Betwixt).  This is one of the reasons we are interested in 
Apache -- we would like to integrate/reuse as much as possible of other
projects, especially if it makes the final product better.  We also
believe that the other projects could benefit from pieces of XMLBeans.

> What's compelling about XMLBeans compared to some of the other front
> runners, such as JDOM and XOM, Castor and JAXB?

The main difference between XMLBeans and JDOM or XOM is that XMLBeans
does not create objects for each XML information item.  Instead, it 
provides cursor-based access to each item in the XML Infoset.  It has
an architecture where, if an actual object is needed for a node, it 
can be created on-demand.  We found this provided great performance 
benefit.  The biggest differences between XMLBeans and Castor or JAXB
1) the goal of 100% Schema support (currently supports everything in 
Schema other than redefine and substitution groups, and those features
are nearly ready), and 
2) the integrated and synchronized access of the underlying XML content
with strongly typed Java classes.

>> ''Meritocracy: ''
>> We would very much like to see XMLBeans evolve under the
>> meritocracy model that is used within Apache.
> The advice I got is still good ... get your meritocracy working RIGHT
> NOW.  I personally found big benefits to reoganizing along these
> lines; it would have been worth the effort even if Tapestry hadn't
> made it all the way in.  The meritocracy really works to get people
> motivated and contributing. 

I agree.  We spent a lot of time thinking about the best community
structure for XMLBeans and decided that the meritocracy by Apache was
the model that we wanted to follow.  We've made the first steps in this
direction, but we are now trying to go all the way with it.  Whether 
Apache is the right place for XMLBeans or not, we will be following the
meritocracy model.  In fact, we are looking at starting open source 
projects around several other technologies we've recently developed,
and even though many of these won't be appropriate for Apache, we will
still will be following a meritocracy model since we are also convinced
that it really does work.

>> ''Core Developers:''
>> In addition to key members of the XMLBeans development team,
>> the initial committers include developers from outside BEA
>> who have spent several months using XMLBeans to solve their
>> particular development needs.
> Be prepared to document a bit more about outside developers'
> contributions. 

To be clear, the outside developers have only recently had the
opportunity to submit patches, but they have been working closely
with the BEA development team for six months by submitting bugs
and feature requests based on the problems that they would run
into while developing against XMLBeans within each of their

> I've learned the hard way to get rid of all [L]GPL dependencies
> before you attempt to move to Jakarta.

It's not even a question for us.  We are in the process of dealing
with this now.  I just wanted to let you all know that we were
handling it.

> Do you have a roadmap of where you would like this project to be in 6
> months?  A year?  Two years? 

Yes - and I will post it shortly on the Wiki site.

> What licensing to you currently use?  LGPL is a problem, BSD or ASL
> is the way to go.  (Pardon me if this is on the pages you've linked
> to ... I haven't clicked through yet). 

We currently use an Apache-style license.  

>> '''(5) identify apache sponsoring individual '''
>> * Steven Noels (
> That's a good step!

Yes - Steven has been incredibly helpful by allowing me to bounce ideas
off him about how BEA can get involved with the open source community,
and specifically if and how XMLBeans would be complement Apache.

> I'd be interested to know why you feel the project will benefit from
> hosting at Jakarta?  My personal experience with Tapestry is that the
> move to Jakarta was good for exposure ... but Tapestry, regretably,
> did not have a major player (such as BEA) backing it.  Eclipse, for
> example, self-hosts, yet is taken very seriously as an open source
> project.  

We are looking at open sourcing other BEA technologies, some of which
would probably make the most sense in a self-hosted community, especially
ones that we don't think Apache would be interested in.  One reason we
are approaching Jakarta with XMLBeans is because we really believe that 
there is a mutually complementary relationship between XMLBeans and 
other projects throughout Apache.  We also think we really have something 
special with XMLBeans; I think it's one of the most innovative components
BEA has come up with (ok -- I'm a little biased ;-), but we also think
it could evolve much further and work with other projects better.  So,
in my view, if we want to show we are serious about open source 
development, we start with something we think is really valuable.

> I'd say you'd want to do as much setup before incubation as possible.
> This includes normalizing your code layout (something that didn't
> materialize for Tapestry, unfortunately) to match the other Jakarta
> projects (this will ease things if and when you transition to Maven
> builds).  You probably want to check out a bit about Gump as well ...
> I can think of one person who will probably veto you until you are
> integrated into Gump.  It's *exceptionally* painful to work with Gump
> at the moment, but ultimately worth it.  

Thanks for the advice - I'll start on this now.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message