incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Leung <>
Subject Re: XMLBeans status report, Jan 2004
Date Sun, 18 Jan 2004 19:56:18 GMT
This looks accurate to me.

I did update the status file in the incubator cvs @ 
cvs:incubator/site/projects/xmlbeans.cwiki, but I'm not sure how to get 
the site to rebuild.

As mentioned below, the big challenge is to grow the community.


On Jan 17, 2004, at 2:48 PM, David Remy wrote:

> - Status report for the Incubator -
> (sorry for the delay, also thanks to xmlbeans-dev list for their quick 
> response - well, delayed quick response ...)
> Overall the xmlbeans project is progressing with good committer
> productivity and a growing user community.  Converting over the Apache
> CVS systems and build process has been accomplished along with various
> other Apache administrative tasks such as setting up the Apache 
> website.
> There is some movement towards growth in the development side of the
> community with one contributor (Dutta Satadip) submitting a nice
> enhancement and several other contributors submitting small patches
> related to bugs.
> More on each of the bullet points below.
> * is the STATUS file up to date? (also post link)
> <Cliff Schmidt>
> We need to update the status file with the latest incubator guidelines.
> We're mostly there, but there are a couple things that need to be 
> added.
> I also think the status file needs to be updated in one or two other 
> ways.
> For instance, the tasks completed should now include:
> - build xmlbeans website
> - grant some committers access to xml-site (Cliff and Remy)
> </Cliff Schmidt>
> * any legal, cross-project or personal issues
>   that still need to be addressed?
> In general it appears xmlbeans is through most of the known issues 
> that existed getting started.  The committers have been able to be 
> productive and there is a lot of code being created in version 2 and 
> fixes are being made into version 1.
> One issue that we have run into is how best to accommodate commonly 
> used api jars primarily (but not exclusively) JCP related api's from 
> SUN.  We are not sure the appropriate process to determine whether we 
> can use a particular jar and host the jar in the xmlbeans build.  
> examples of api's that we are unsure the appropriate/best way to deal 
> with are:
>   * JSR173 api and JSR 173 RI (Streaming API for XML, a.k.a., STAX) - 
> the JSR173 RI dependency is temporary.  Currently xmlbeans downloads 
> it from external server during the build process
>   * SAAJ api - we used the saaj-api source code in axis.
>   * xml commons resolver (Apache jakarta)
>   * jaxen  ( - apache-style license, but not 
> apache)

The deterimining factor is the licensing.  If the license is ASF 
compatible then there shouldn't be a problem hosting it.  How to manage 
the version dependencies is up to us.

> Here are some specific questions on this subject that David Bau posted:
> <David Bau>
> - We currently load resolver.jar and jaxen.jar if the user happens to 
> put
> them on the classpath, and throw a runtime exception if the user tries 
> to
> use a resolver- or jaxen- dependent feature without those JARs present.
> This is OK, but it would be nicer for users if resolver and jaxen were 
> just
> included in xbean.jar, but this presents both licensing issues (for 
> jaxen)
> and possible-version-conflict issues (for commons resolver).  A 
> question is:
> is there a nice way we include resolver.jar and jaxen.jar inside 
> xbean.jar,
> or should we stay away from that idea?
> - We need the JSR 173 API to run, and this is definitely something 
> that we
> want to be able to distribute either directly inside xbean.jar, or at 
> least
> directly inside Apache since it's so core.  In other words, we can't 
> expect
> users to do anything without this API present.  I've noticed that for 
> other
> APIs, such as SAAJ, Apache seems to have a "clean room" copy of the 
> APIs.
> Should we be making such a copy of the JSR 173 APIs?  What is the 
> right way
> to do this?
> </David Bau>
> * what has been done for incubation since the last report?
> <David Bau>
> The main thing is that we've been working on the project.  We're 
> getting
> more folks hanging around on the lists; we're getting some of the code 
> that
> we've talked about on the lists and on the wiki actually written and 
> checked
> in.  We've been encouraging the wider community to critique and 
> contribute
> ideas and code. Community-building is a gradual process; we don't have 
> a
> mature community yet, but we've certainly gotten started at building a 
> little
> one.
> </David Bau>
>  *  source code checkin (was that since last status report?)
>  *  build and test ant scripts established
>  *  website updated including docs, source code access, etc.
>  *  established version 2 effort and modified CVS tree accordingly
>  *  proposed (close to implementing I think) branching strategy for 
> version 1 (by Kevin Krouse)
>  *  gump integration (thanks to Robert Burrell Donkin)
> * plans and expectations for the next period?
>  * development on v2 will continue incorporating community feedback.
>  * continued work on soliciting volunteers for contribution and 
> committership.
>  * work on organizing bug tracking and follow up
>  * xmlbeans-1.01 distribution (minor bug fixes to v1)
>  * improve process of bug testing and fixing from BugZilla 
> contributions.
> * any recommendations for how incubation could run
>    more smoothly for you?
> Incubation seems to be going well with one, albeit an important one,
> challenge of getting outside committers.  Having a large existing
> codebase in a fairly complicated area makes it challenging.  The 
> growing
> user community and the excellent posts that we are getting on the
> xmbleans-dev list make us optimistic we will make some breakthroughs
> in the next period.
> * things that xmlbeans could/will improve on (summary, contributed by 
> Cliff Schmidt)
> 1. Bug management: 
> (as has already been mentioned by one or two others)
> -- This is just as much related to community as code.  Of the 12 bugs
> entered so far, we haven't done a very good job of keeping them updated
> with status.  We should encourage people to file bugs by showing that
> the committers are actually responding to them (even if the response
> is "need more info to repro" or simply noting the priority).
> 2. Web site:
> -- We got this built and running but we need to keep it updated.  For 
> instance, it still shows the ApacheCon advertisement.
> 3. Binary download.
> -- We started to get this done, but I don't think we ever finished.  
> Actually, I'd like to try to get this done in the next couple days.
> 4. PPMC
> -- The incubator introduced the idea of a PPMC and we haven't responded
> to this yet.  I'll follow up in a separate post on what needs to be 
> done.
> 5. Status file
> -- We need to update the status file with the latest incubator 
> guidelines.
> We're mostly there, but there are a couple things that need to be 
> added.
> I also think the status file needs to be updated in one or two other 
> ways.
> For instance, the tasks completed should now include:
> - build xmlbeans website
> - grant some committers access to xml-site (although I forgot who has 
> this;
> I think it is me and Remy)
> 6. Committer keys
> Bau and I were both able to make it to ApacheCon and we both 
> participated in
> the key-signing party.  We need to get other committers to make keys 
> and
> get them signed by me and Bau whenever we run into each other in person
> again.
> 7. New Committers
> The biggest issue of all is definitely the new committers, as everyone
> seems to agree.  We really need to find more ways to encourage others 
> to
> contribute.   I think we are all ready and willing to share some of the
> responsibility; we just need to find people who are showing enough 
> interest
> (and action) to be considered for committership.
> - ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> Apache XMLBeans Project -- URL:

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

View raw message