> On Feb 22, 2017, at 12:24 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > 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].
I’m quite aware of that, I’m also on the Aries PMC and follow that stuff closely. :) > It was working well, with a couple of caveats. > > We had considered to contribute some API and implementation improvements to > make library use simpler. We’d love to have any contributions! Submit away! 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. That’s my point. From what I could tell from a cursory look through your report (I could have missed things), almost all of the changes are implementation specific and thus, should not have any impact on the version as exposed to the cxf user (as opposed to internal cxf developer). So, back to my original question: what impact did moving from 3.0.3 to 3.1.9 have? Was there anything that you encountered that is not mentioned in the migration guide? http://cxf.apache.org/docs/31-migration-guide.html Dan > > Sincerely, > - Ray > > [1] https://github.com/osgi/design/tree/master/rfcs/rfc0217 > > On Wed, Feb 22, 2017 at 12:01 PM, Daniel Kulp <dk...@apache.org> wrote: > >> >>> On Feb 22, 2017, at 11:23 AM, Raymond Auge <raymond.a...@liferay.com> >> 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 <dk...@apache.org> wrote: >>> >>>> >>>>> On Feb 21, 2017, at 11:53 AM, Raymond Auge <raymond.a...@liferay.com> >>>> 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 >>>> dk...@apache.org - 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 >> dk...@apache.org - 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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
