And, I've got a set of XML processing utilities for DOM and for XSD
validation that I'll commit to NetUI under:
org.apache.beehive.netui.util.xml
Unfortunately, these probably won't be useful for things in the Page
Flow compiler or in the EJB Control. If you use utility things there,
we might try to protect them as much as possible so we keep the API
surface area to a minimum and don't become a provider of XML utils.
:)
EKO
Rich Feit wrote:
Thanks Carlin, that would be really helpful. Basically, the
ProcessedAnnotations XMLBean would need to get replaced with some other
bean. It's a simple schema (annotated-element(s) -> [element-name,
processed-annotation(s) -> [annotation-name, annotation-attr(s) ->
[attr-name, attr-value]]]). The only thing to note is that it's
recursive: an annotation-attr can contain a processed-annotation as its
value. Let me know if you have any questions about it.
Rich
Carlin Rogers wrote:
I can help out and take alook at the runtime support for the Processed
Annotations you mentioned Rich.
On 9/14/05, Rich Feit <[EMAIL PROTECTED]> wrote:
Assuming we do this, I'll take everything under netui/src/compiler-core
(generation of config files for Struts, Validator, Processed Annotations).
Rich
Carlin Rogers wrote:
Thanks for the update Eddie. I like option three (non-binding, not a
committer), shipping 1.0 without XMLBeans dependence but still support
XMLBean-related features for the users. I agree with the additional
benefits
both you and Rich have outlined.
The URL template config file parsing in the DefaultURLTemplatesFactory is
straightforward and can easily be implemented with DOM. Depending on the
discussion and direction taken, I can contribute a patch with changes in
the
DefaultURLTemplatesFactory to support option 3.
Carlin
On 9/14/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I definitely think we should go with option #3. We would continue to
support XMLBeans in Beehive features (e.g., using an XMLBean directly as
a form bean for a Page Flow action), but there's no urgent need to use
XMLBeans internally for things like writing out Struts config files
(which don't even have an official schema). This also lets us avoid
forcing a particular version of apache-xbean.jar on our users.
Rich
Eddie O'Neil wrote:
All--
If you've been following the JSR 173 discussion with XMLBeans, you
know that we've been discussing a licensing issue around these APIs.
At this point, the Beehive 1.0 is effectively blocked on XMLBeans
resolving this licensing problem.
In order to ship Beehive 1.0 in the next few days, I see us at a
point where we have some hard decisions to make. Some options:
1) hold the Beehive ship for resolution to the licensing issue. It's
not clear how long this will take; I've been in some discussions with
BEA Legal, and it's possible that this could take a bit to figure out.
But, it's hard to tell...hopefully some discussion / update of this
will happen on [EMAIL PROTECTED]
2) ship Beehive 1.0 but require end-users to download JSR 173 and
accept its license. Until users do this, it won't be possible to use
Page Flow. Personally, I'm not fond of this option because it forces
those interested in using Beehive to perform additional assembly in
order to make the distribution work. It also forces acceptance of the
JSR 173 license, which some organizations might not like
3) decouple from having a binary dependence on XMLBeans. In the form
Beehive will ship for 1.0, this includes removing this dependence in
NetUI and the shipping system controls (EJB, JMS, and JDBC). Controls
doesn't have an XMLBean dependency. NetUI has a binary dependency on
XMLBeans in the compiler at build-time and for some XML parsing done
at run time.
Honestly, I'm *dying* to ship Beehive 1.0 :) and would pick option (3)
above. I've taken a crack at rewriting the parsing for the
beehive-netui-config.xml file, and it wasn't difficult to do. It also
seems possible to have Beehive *support* XMLBean features that aren't
enabled by default. For example, in the JdbcControl today, it's
possible to map a ResultSet onto an XMLBean, but this type converter
isn't required by default and is enabled based on *use* of XMLBeans,
which implies its presence.
So, in (3), we could take the stance that Beehive 1.0 ships without
XMLBeans but that XMLBean-related features can be enabled if Beehive
users wish to download XMLBeans and use it with our distribution.
Seems like we could do this with *no loss of features*.
This also has a few benefits:
1) the distribution download will be somewhat smaller (maybe 15% or
more?)
2) we don't prescribe a version of XMLBeans and let users pick a
version
to use
3) selfishly, developing Beehive in an IDE gets easier because schemas
don't need to be generated on the command line :)
Let's discuss our options for a bit and then put it up for a
vote...additional thoughts / comments?
Eddie
On 9/11/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
And, of course, the link helps...
http://mail-archives.apache.org/mod_mbox/xmlbeans-dev/200509.mbox/[EMAIL
PROTECTED]
:)
On 9/11/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
Just to keep everyone updated...
This is the most recent post from Cliff into the [EMAIL PROTECTED]
mailing list. Looks like we're not quite out of the woods yet on the
JSR 173 API licensing issue.
I'll send more info along as I see it...
Eddie
On 9/8/05, Rich Feit <[EMAIL PROTECTED]> wrote:
I agree -- great news. Thanks for dealing with it! 1.0, here we
come...
Rich
Eddie O'Neil wrote:
Steve--
I don't see any additional blocking ones in JIRA and agree -- seems
like it's time to cut a branch. Will spin out a vote on doing so...
Eddie
On 9/8/05, Steven Tocco <[EMAIL PROTECTED]> wrote:
Eddie,
That is great news!
Are there any other blocking issues preventing a branch being
created
for v1?
Thanks
Steve
-----Original Message-----
From: Eddie O'Neil [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 08, 2005 2:51 PM
To: Beehive Developers
Subject: Re: xmlbeans, jsr173, and BEEHIVE-872
All--
I just committed a change that switches Beehive onto the new JSR
173
API package. This has been vetted by the appropriate lawyers to
ensure that the license for the 173 API JAR is Apache compatible
and
can be shipped with a Beehive distribution.
The XMLBeans committers are asking for advice from ASF folks about
what to do with their 2.0 release. I suppose it's possible that
they'll need to re-roll the release. If that happens, we'll need
to
decide whether to upgrade the XMLBean version we ship, though I'd
guess any new version they release will be compatible with the 2.0
>from June.
The change I committed does a few things:
- switches the download package for JSR 173 from
http://workshop.bea.com/xmlbeans
- bundles the new JSR 173 API JAR in a distribution
- adds a LICENSE.jsr173-api file to both SVN and to the
distribution
I'm going to go ahead and close the JIRA issue since our license
issue should be resolved; let's watch dev@ to see where XMLBeans
goes
with this next.
Questions / comments?
Eddie
On 9/7/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
Oh, yeah...here's the XMLBeans change from this morinng about the
JSR 173 bundle:
http://mail-archives.apache.org/mod_mbox/xmlbeans-commits/200509.mbox/%3
[EMAIL PROTECTED]
On 9/7/05, Eddie O'Neil <[EMAIL PROTECTED]> wrote:
All--
If you've been reading the release status e-mails that have been
in
the list, you've noticed that BEEHIVE-872 is tracking a license
issue
with XMLBeans and their dependency on the JSR 173 API JAR. There
was
a change in the XMLBeans mailing list this morning that switched
onto
a new JSR 173 download bundle that has some different license
verbage
in it.
There's mail in [EMAIL PROTECTED] that checks to make sure that the
license issue is resolved, but if it's taken care of from their
side,
I'm sitting on a change that will add the correct license to our
SVN
tree and download and will switch us onto the new JSR 173
package.
Once the status of this is clear, I'll commit that and resolve
the
1.0
blocking JIRA issue.
Eddie
