You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlbeans-dev@xml.apache.org by David Remy <dr...@bea.com> on 2004/01/16 21:18:39 UTC
xmlbeans status report
hey committers and xmlbeans community,
we are overdue for a status report on xmlbeans progress. i will put down a few of my thoughts here but i could use feedback. i would like to post a status report to the incubator team by end of day today if that is possible so please respond quickly. thx.
> Status report for the Incubator
>
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 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)
It looks to me that the status file is up to date. Is there any other things that need to be added or update there? Cliff, do you think you could take a look at it? http://incubator.apache.org/projects/xmlbeans.html
> * 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 relatively minor issue that we have run into is how best to accomodate commonly used api jars primarily JCP related api's from SUN. For example right now the JSR173 (Streaming API for XML, a.k.a., STAX) api jar is hosted on an non-Apache server and brought down on the build process (if it doesn't already exist on the machine). There have been similar questions about SAAJ however we found a SAAJ api jar in the AXIS project with an Apache license. We are unsure what the right process for determining whether we can use a particular jar and host the jar in our build (esp the SUN JCP jars).
>
> * what has been done for incubation since the last report?
cliff and david (et al.) I will probably need your help here:
* 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 to provide
cezar, did you do something related to gump that should be reflected here?
kevin krouse, is there anything here that you might want to add?
>
> * 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 distrubution (minor bug fixes to v1)
what else?
> * 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 break throughts in the next period.
We have had really great support from the Incubator team and our Mentor Ted Leung especially early on as we were working to get the source code in, get the website updated, and establishing a place where developers could be productive. I don't know of a situation where we did not get what we needed from the incubation team.
> * etc (your own thoughts on what is important would be helpful!)
As a technology xmlbeans 1.0 seems to be gaining a lot of momentum in the user community and is an extremely strong XML Java binding option for people that require strong XML schema compliance and full fidelity marshalling. We are pretty excited about XMLBeans Version 2 since it expands the scope to support quite a few more use cases including a lossy scenario, DOM Level 2, a pluggable backend data store capability, and a lot more. The architectural and coding aspects are challenging and a lot of fun.
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by robert burrell donkin <rd...@apache.org>.
On 18 Jan 2004, at 01:58, Brian McCallister wrote:
> On Jan 16, 2004, at 3:18 PM, David Remy wrote:
>
>> 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 break
>> throughts in the next period.
>
> I think there are probably people who want to contribute to (and make
> more use of) xmlbeans but you nailed it -- it is big, sophisticated,
> and not working with a well-understood (by most people in positions to
> contribute) technology.
yep.
it's quite possible that xml beans is having to fight against one of
stefano's rules for (apache) project building: the difficulty of
building a good developer community is in proportion to the quality of
the starting code base. in other words, given the same quality of
vision, it's easier to create a good developer community around a poor
quality code base than a good quality one.
of course, that doesn't mean that the thing to do is to throw out all
that good code ;)
but it's worth remember that if you've already got good code, community
building is going to take more time.
- robert
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by robert burrell donkin <rd...@apache.org>.
On 18 Jan 2004, at 01:58, Brian McCallister wrote:
> On Jan 16, 2004, at 3:18 PM, David Remy wrote:
>
>> 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 break
>> throughts in the next period.
>
> I think there are probably people who want to contribute to (and make
> more use of) xmlbeans but you nailed it -- it is big, sophisticated,
> and not working with a well-understood (by most people in positions to
> contribute) technology.
yep.
it's quite possible that xml beans is having to fight against one of
stefano's rules for (apache) project building: the difficulty of
building a good developer community is in proportion to the quality of
the starting code base. in other words, given the same quality of
vision, it's easier to create a good developer community around a poor
quality code base than a good quality one.
of course, that doesn't mean that the thing to do is to throw out all
that good code ;)
but it's worth remember that if you've already got good code, community
building is going to take more time.
- robert
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Brian McCallister <br...@apache.org>.
On Jan 16, 2004, at 3:18 PM, David Remy wrote:
> 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 break
> throughts in the next period.
I think there are probably people who want to contribute to (and make
more use of) xmlbeans but you nailed it -- it is big, sophisticated,
and not working with a well-understood (by most people in positions to
contribute) technology.
I have plans for using xmlbeans, and hope to be able to contribute back
once I start actually using it for more than testing out my
understanding of schemas, but this whole xsd thing takes a while to get
really comfortable with =)
-Brian
- ---------------------------------------------------------------------
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/
Bugzilla/JIRA
Posted by Brian McCallister <mc...@forthillcompany.com>.
Thought on the bug tracker -- if there are few bugs in the system
already it may be worth swapping to the new JIRA instance rather than
using Bugzilla as it is a bit handier for a lot of things --
particularly the future planning and status tracking areas.
-Brian
- ---------------------------------------------------------------------
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/
Bugzilla/JIRA
Posted by Brian McCallister <mc...@forthillcompany.com>.
Thought on the bug tracker -- if there are few bugs in the system
already it may be worth swapping to the new JIRA instance rather than
using Bugzilla as it is a bit handier for a lot of things --
particularly the future planning and status tracking areas.
-Brian
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Michael Allman <ms...@nfcexperts.com>.
David,
What you have looks good.
I put on my editor's hat and fixed a few minor grammar and spelling errors
(below).
Michael
On Fri, 16 Jan 2004, David Remy wrote:
> hey committers and xmlbeans community, we are overdue for a status
> report on xmlbeans progress. i will put down a few of my thoughts here
> but i could use feedback. i would like to post a status report to the
> incubator team by end of day today if that is possible so please respond
> quickly. thx.
>
> > Status report for the Incubator
> >
> 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 setting up the Apache website.
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)
>
> It looks to me that the status file is up to date. Is there any other
> things that need to be added or update there? Cliff, do you think you
> could take a look at it?
> http://incubator.apache.org/projects/xmlbeans.html
>
> > * 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 relatively minor issue that we have run into is how best to
> accomodate commonly used api jars primarily JCP related api's from SUN.
> For example right now the JSR173 (Streaming API for XML, a.k.a., STAX)
> api jar is hosted on an non-Apache server and brought down on the build
> process (if it doesn't already exist on the machine). There have been
> similar questions about SAAJ however we found a SAAJ api jar in the AXIS
> project with an Apache license. We are unsure what the right process
project with an Apache license. We are unsure of the right process
> for determining whether we can use a particular jar and host the jar in
> our build (esp the SUN JCP jars).
>
> >
> > * what has been done for incubation since the last report?
>
> cliff and david (et al.) I will probably need your help here:
>
> * 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 to provide
>
> cezar, did you do something related to gump that should be reflected here?
> kevin krouse, is there anything here that you might want to add?
>
> >
> > * 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 distrubution (minor bug fixes to v1)
xmlbeans-1.01 distribution (minor bug fixes to v1)
> what else?
>
>
> > * 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 break throughts
xmbleans-dev list make us optimistic we will make some breakthroughs
> in the next period.
On a side note, I am evaluating XMLBeans for use in future projects of my
own. If I end up using XMLBeans, and I do like what I see so far, I would
be happy to contribute to development.
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by David Bau <da...@bea.com>.
Thanks Dave for organizing this, and thanks Steven+Ted for encouraging us to
get off our lazy butts!
> One relatively minor issue that we have run into is how best to accomodate
commonly used api jars
Yah, this is a question that I'd particularly love to have advice and
assistance on from the incubator experts.
Here is the list I get from our current build (Remy, where are the SAAJ APIs
getting picked up from?)
JSR 173 API. (Our public API in our v2 is going support JSR 173 in a few
ways, and so we need this API.)
JSR 173 RI. (The dependency on the RI for 173 is temporary, because we'll
be shifing to our own apache 173 impls.)
xml-commons-resolver (Apache Jakarta)
jaxen (jaxen.sourceforge.net - apache-style license, but not apache)
In order to avoid distribution licensing issues, none of these JARs are
currently checked into Apache CVS, which means that when you do a build that
depends on any of these JARs, you must download them directly from the
non-Apache source. Although this means our build is slightly more clumsy,
it is automated and it seems OK.
It would be great to ask for advice from the veterans and incubator types as
to what to do about these JARs in our runtime footprint. In particular, it
seems like we can't actually distribute a compiled binary that includes any
of the code from non-Apache JARs. (Is that right? What about "Apache-like"
licenses?) Here are my questions.
- 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?
>> * what has been done for incubation since the last report?
> cliff and david (et al.) I will probably need your help here:
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, but we've certainly gotten started at building a little
one.
>> * plans and expectations for the next period?
> what else?
Your list looks good to me.
>> * 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.
Yes, this is hard - it is a lot of code. Growing committer diversity it is
the main thing we need to work on. But we are starting to see some "users
turn into contributors", and so it is encouraging.
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Michael Allman <ms...@nfcexperts.com>.
David,
What you have looks good.
I put on my editor's hat and fixed a few minor grammar and spelling errors
(below).
Michael
On Fri, 16 Jan 2004, David Remy wrote:
> hey committers and xmlbeans community, we are overdue for a status
> report on xmlbeans progress. i will put down a few of my thoughts here
> but i could use feedback. i would like to post a status report to the
> incubator team by end of day today if that is possible so please respond
> quickly. thx.
>
> > Status report for the Incubator
> >
> 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 setting up the Apache website.
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)
>
> It looks to me that the status file is up to date. Is there any other
> things that need to be added or update there? Cliff, do you think you
> could take a look at it?
> http://incubator.apache.org/projects/xmlbeans.html
>
> > * 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 relatively minor issue that we have run into is how best to
> accomodate commonly used api jars primarily JCP related api's from SUN.
> For example right now the JSR173 (Streaming API for XML, a.k.a., STAX)
> api jar is hosted on an non-Apache server and brought down on the build
> process (if it doesn't already exist on the machine). There have been
> similar questions about SAAJ however we found a SAAJ api jar in the AXIS
> project with an Apache license. We are unsure what the right process
project with an Apache license. We are unsure of the right process
> for determining whether we can use a particular jar and host the jar in
> our build (esp the SUN JCP jars).
>
> >
> > * what has been done for incubation since the last report?
>
> cliff and david (et al.) I will probably need your help here:
>
> * 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 to provide
>
> cezar, did you do something related to gump that should be reflected here?
> kevin krouse, is there anything here that you might want to add?
>
> >
> > * 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 distrubution (minor bug fixes to v1)
xmlbeans-1.01 distribution (minor bug fixes to v1)
> what else?
>
>
> > * 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 break throughts
xmbleans-dev list make us optimistic we will make some breakthroughs
> in the next period.
On a side note, I am evaluating XMLBeans for use in future projects of my
own. If I end up using XMLBeans, and I do like what I see so far, I would
be happy to contribute to development.
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Kevin Krouse <kk...@bea.com>.
> >
> > * what has been done for incubation since the last report?
>
> cliff and david (et al.) I will probably need your help here:
>
> * 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 to provide
>
> cezar, did you do something related to gump that should be reflected here?
> kevin krouse, is there anything here that you might want to add?
>
As far as branching and preparing for a 1.0.1 release goes, Remy and I
created a branch off of the v1 code line named 'xmlbeans-1-0-1_branch'.
In this branch, we'll tag a release after a few more checkins can be
made and testing can assure of high quality. There have been some
contributions sitting in Bugzilla and on the mailing list that have yet
to be applied. Sorry for being slow. Only bug fixes go into this
branch and they should be merged into the v1 main trunk as well as the
v2 main trunk.
The main trunk of v1 is still in the 'active development' even though no
new features are planned. All of the exciting new stuff is going into
the v2 main trunk.
> >
> > * 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 distrubution (minor bug fixes to v1)
>
yeah, we need to be a little faster in the bug testing and fixing from
the BugZilla contributions.
--
Kevin Krouse
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Kevin Krouse <kk...@bea.com>.
> >
> > * what has been done for incubation since the last report?
>
> cliff and david (et al.) I will probably need your help here:
>
> * 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 to provide
>
> cezar, did you do something related to gump that should be reflected here?
> kevin krouse, is there anything here that you might want to add?
>
As far as branching and preparing for a 1.0.1 release goes, Remy and I
created a branch off of the v1 code line named 'xmlbeans-1-0-1_branch'.
In this branch, we'll tag a release after a few more checkins can be
made and testing can assure of high quality. There have been some
contributions sitting in Bugzilla and on the mailing list that have yet
to be applied. Sorry for being slow. Only bug fixes go into this
branch and they should be merged into the v1 main trunk as well as the
v2 main trunk.
The main trunk of v1 is still in the 'active development' even though no
new features are planned. All of the exciting new stuff is going into
the v2 main trunk.
> >
> > * 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 distrubution (minor bug fixes to v1)
>
yeah, we need to be a little faster in the bug testing and fixing from
the BugZilla contributions.
--
Kevin Krouse
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by David Bau <da...@bea.com>.
Thanks Dave for organizing this, and thanks Steven+Ted for encouraging us to
get off our lazy butts!
> One relatively minor issue that we have run into is how best to accomodate
commonly used api jars
Yah, this is a question that I'd particularly love to have advice and
assistance on from the incubator experts.
Here is the list I get from our current build (Remy, where are the SAAJ APIs
getting picked up from?)
JSR 173 API. (Our public API in our v2 is going support JSR 173 in a few
ways, and so we need this API.)
JSR 173 RI. (The dependency on the RI for 173 is temporary, because we'll
be shifing to our own apache 173 impls.)
xml-commons-resolver (Apache Jakarta)
jaxen (jaxen.sourceforge.net - apache-style license, but not apache)
In order to avoid distribution licensing issues, none of these JARs are
currently checked into Apache CVS, which means that when you do a build that
depends on any of these JARs, you must download them directly from the
non-Apache source. Although this means our build is slightly more clumsy,
it is automated and it seems OK.
It would be great to ask for advice from the veterans and incubator types as
to what to do about these JARs in our runtime footprint. In particular, it
seems like we can't actually distribute a compiled binary that includes any
of the code from non-Apache JARs. (Is that right? What about "Apache-like"
licenses?) Here are my questions.
- 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?
>> * what has been done for incubation since the last report?
> cliff and david (et al.) I will probably need your help here:
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, but we've certainly gotten started at building a little
one.
>> * plans and expectations for the next period?
> what else?
Your list looks good to me.
>> * 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.
Yes, this is hard - it is a lot of code. Growing committer diversity it is
the main thing we need to work on. But we are starting to see some "users
turn into contributors", and so it is encouraging.
- ---------------------------------------------------------------------
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/
Re: xmlbeans status report
Posted by Brian McCallister <br...@apache.org>.
On Jan 16, 2004, at 3:18 PM, David Remy wrote:
> 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 break
> throughts in the next period.
I think there are probably people who want to contribute to (and make
more use of) xmlbeans but you nailed it -- it is big, sophisticated,
and not working with a well-understood (by most people in positions to
contribute) technology.
I have plans for using xmlbeans, and hope to be able to contribute back
once I start actually using it for more than testing out my
understanding of schemas, but this whole xsd thing takes a while to get
really comfortable with =)
-Brian
- ---------------------------------------------------------------------
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/