> On Feb 22, 2017, at 1:14 PM, Raymond Auge <[email protected]> wrote: > > On Wed, Feb 22, 2017 at 12:40 PM, Daniel Kulp <[email protected]> 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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
