As you are eluding to CXF being a black box, I find that to be a sad thing as Apache Aries is using individual parts of CXF as libraries to build a dynamic, more focused, smaller footprint RI for OSGi RFC-217 JAX-RS Services [1].
It was working well, with a couple of caveats. We had considered to contribute some API and implementation improvements to make library use simpler. Sincerely, - Ray [1] https://github.com/osgi/design/tree/master/rfcs/rfc0217 On Wed, Feb 22, 2017 at 12:01 PM, Daniel Kulp <[email protected]> wrote: > > > On Feb 22, 2017, at 11:23 AM, Raymond Auge <[email protected]> > wrote: > > Some issues are visible in this baseline report (look for instance of > > MAJOR): > > > > https://gist.github.com/rotty3000/051db70089947914205a62f210b3be87 > > And how did ANY of that affect your application? That’s the point. > > Looking through that entire list, there is exactly one thing that could > potentially have required a version update: > > Removal of Message.setContextualProperty - however, this method was not > meant to ever be exposed and was completely broken in 3.0.x. It would not > have done what anyone would have expected and, more important, any property > set via this method would have potentially bean lost on a context recalc. > > > Everything else in your report is non-User stuff and thus is not an issue. > > > So basically it’s just a removal of a single method that didn’t work and > shouldn’t have been exposed to the user or called by them. Not a “4.0” > change. > > > Dan > > > > > > > > Sincerely, > > - Ray > > > > On Wed, Feb 22, 2017 at 10:48 AM, Daniel Kulp <[email protected]> wrote: > > > >> > >>> On Feb 21, 2017, at 11:53 AM, Raymond Auge <[email protected]> > >> wrote: > >>> > >>> Hello everyone, > >>> > >>> This is my first post to the list. So thank you in advance for all your > >>> hard work and very good product. > >>> > >>> However, I have a question about semantic versioning of CXF. > >>> > >>> In our project we are using CXF (piecemeal). > >>> > >>> However when we upgraded our dependency from 3.0.3 to 3.1.9 we > >> encountered > >>> MAJOR api changes while baselining. > >> > >> What kind of major changes? User code should rebuild/re-compile > without > >> problem when moving from 3.0.x to 3.1.x. > >> > >> > >>> It seems that there are many semantically invalid changes on this > >> apparent > >>> _minor_ release. I wondered if the CXF project knows that some changes > >> are > >>> not semantically correct or was simply an oversight? > >>> > >>> Would the CXF project entertain adding baseline checks to the build to > >>> assert semantic versioning? > >> > >> Probably not. The semantic versioning that we care about is if apps > >> written to JAX-WS and/or JAX-RS and use the “normal” configuration > >> mechanisms (spring/blueprint) will re-compile and run without > >> modification. Any API changes within CXF modules or between them is > not > >> something we worry about. > >> > >> -- > >> Daniel Kulp > >> [email protected] - http://dankulp.com/blog > >> Talend Community Coder - http://coders.talend.com > >> > >> > > > > > > -- > > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > > (@rotty3000) > > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > > (@Liferay) > > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> > (@OSGiAlliance) > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
