(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 [http://workshop.bea.com/xmlbeans/quickStart.jsp 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 are: 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 applications. > 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. See http://workshop.bea.com/xmlbeans/XsdUpload.jsp. >> '''(5) identify apache sponsoring individual ''' >> >> * Steven Noels ([EMAIL PROTECTED]) > > 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. Cliff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
