xml-xmlbeans-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Bau" <david....@bea.com>
Subject Re: xmlbeans status report
Date Fri, 16 Jan 2004 21:05:00 GMT
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

>>  * 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
> 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/

View raw message