cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Thoughts about a 2.8 release (or not)…
Date Wed, 27 Mar 2013 17:57:05 GMT

On Mar 27, 2013, at 1:35 PM, Glen Mazza <> wrote:

> Dan's quote: According to the agreements Apache has with Oracle, we really
> cannot "release" code that doesn't pass the TCK (which the 2.0 works would
> not).
> I'm confused -- Apache FOP, Maven and Tomcat can release whenever they want,
> even though none of them even remotely pass the JAX-RS TCK either.  Can you
> spell out precisely why CXF has that restriction?   Apache makes maybe 100
> software products, which of them are allowed to be released even though they
> horribly fail the JAX-RS TCK and which ones aren't?

It has to do with the definitions of "product" (defined in the agreement) and what JCP specifications
that "product" implements.   (aka: which API's in javax.* the product implements)   In our
case, "CXF" is the product and we implement (JAX-WS) and (JAX-RS)
and thus are bound to the agreement for those TCK's.   Tomcat implements javax.servlet (and
the jsp and and a couple others) and is bound to the TCK agreement as well for those specs.
   Maven doesn't implement any of the javax.* things and thus, as a "product," is not bound.

> Oracle is a competitor, it would be strange for us to sign up for something
> that limits our ability to make releases (which is what a competitor would
> want).  Further, there is so much more to CXF than just adherence to any one
> particular TCK, it would seem to our heavy detriment if we could no longer
> make releases to make that additional functionality available to the
> community (allowing them to work on it, adopt it, and report bugs to us)
> just because of incomplete TCK compliance in one specification or the other.

Yep.  That's one of the things that bugs me about the agreement.   There's a bunch of other
things I don't like as well.   For example, lets say we DIDN'T want to do JAX-RS 2.0.   That's
not allowed either.   Once 2.0 is final, we have to move to it for future major releases (bug
fix releases can stay on 1.1)  of CXF (there is a time period in there that we are negotiating).

> This also seems to give Oracle an advantage of sorts--Oracle splits its
> services offerings into Metro and Jersey, so a failure in one would mean the
> other still can get released.  With CXF, which supports 2 TCK's, if either
> fail then the entire product line can't be released.

Yep.  One possible solution would be to split the "CXF" product into two separate products
(or 3).   One devoted to SOAP/WS and the other to REST and name them differently and such.
  Thus, one could continue forward.   However, we then would need to manage multiple releases
and version numbers and such which has it's own downsides.   

The other alternative is to "release" milestones that aren't really releases.  That's exactly
what Oracle does.   That's why we have "Jersey 2.0-m12" and such.   The 2.0 TCK isn't final
so it cannot actually implement the spec and thus cannot be a full release per the TCK agreement,
but doing a "milestone" or "beta" or "preview" release is OK.   

In all, much of the agreement sucks.  But Apache has already agreed to most of it years ago.

Daniel Kulp -
Talend Community Coder -

View raw message