cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: CXF and semantic versioning
Date Wed, 22 Feb 2017 18:52:02 GMT

> On Feb 22, 2017, at 1:14 PM, Raymond Auge <> wrote:
> On Wed, Feb 22, 2017 at 12:40 PM, Daniel Kulp <> wrote:
>> CXF is a library, but as with any block of code, there are defined entry
>> points and there are bunch and bunches of things that are considered
>> implementation specific/internal things.  Any changes to the internal
>> things should not have an impact on users and thus shouldn’t affect the
>> versioning.
> Any exported package is API and not internal details.

In an application/bundle that was designed and implemented from the ground up to be used primarily
in OSGi, sure.  I’d agree with that.   However, that’s not CXF.    The OSGi support in
CXF was added several years after the initial design and thus is “restricted” due to how
the library was originally implemented over 11 years ago.  CXF was NOT designed with OSGi
in mind at all and thus shoe-horning OSGi-isms onto it are hard and is definitely not “perfect".

The original guidelines that were used for CXF versioning pretty much came from the company
that most of us worked at at the time (IONA).   Basically, a patch release is a “drop in”
replacement and needs to be completely compatible.   The minor release can require recompiling
existing user applications, but shouldn’t require large refactoring.  Very low-level “plugins”
that were not “user” things and were using undocumented/unsupported things were allowed
to break.   Major releases can obviously go further.   From that, the only things were needed
to care about are the the things that the “user” would use in the application and we mostly
restricted that to “what is documented in the docs”.    At the time, we didn’t even
publish javadocs for everything.  We had a very small “api” jar which is all that got
documented.   (We now publish all the javadoc as it’s useful for CXF developers as well).
 Anyway, during this time period, the code was organized to make it easier to understand and
maintain the code (put all the relevant interceptors together in one spot for example) without
any major concern about which of those are “for users” and which were not.   That’s
what the docs were for.   Thus, packages have mixed use.  (We also had split packages with
packages that existed in several jars)

Anyway, when OSGi support was globbed onto CXF, we pretty much had to export way more than
what “just the users” would use as other modules within CXF need a lot of the things.
  We’d have to break EVERYBODY to refactor things in a way that would just export individual
things.   We made a concious decision that that would be “bad”.  :)   The first “attempt”
at OSGiing CXF involved creating one gigantic bundle.   With that bundle, we could restrict
things down a little.   Many of the packages could be marked private, but things like the
“interceptors” package that has some classes that should not be “user” used, it doesn’t
really help.  This also allowed us to deal with the split package issue.   Obviously the big
bundle had other major problems with it which is why it was abandoned for the smaller individual
bundles.  But doing that did require some work to refactor a lot of internal things to resolve
the split packages.    If we could export various thing ONLY to other cxf modules, we could
certainly make things better (I believe jigsaw will allow that, but not OSGi), but even that
wouldn’t be complete without doing some major breakages.

> It wasn't that there were actually problems caused, other than pure
> semantic compatibility issues as package dependencies expect semantic
> versioning.

OK.  That’s good news.    So “not a problem”.  :)

> We're working through these issues given our better understanding of CXF
> now.. but let's just say it was unexpected.

See above.   It’s mostly historical due to the history of CXF and how it migrated from an
internal IONA project, to Celtix, the merger with XFire, the first several years at Apache,
the initial addition of OSGi support, and finally the ongoing efforts to clean up some of
that.   Sure, we could do a full steam “major version cleanup” and look at every class
and move it to a new package if it’s not supposed to be used or some other mess, but that’s
a TON of work and I think we all have better things to spend our time on.

Daniel Kulp -
Talend Community Coder -

View raw message