On Wed, Feb 22, 2017 at 12:40 PM, Daniel Kulp <[email protected]> wrote:
> > > On Feb 22, 2017, at 12:24 PM, Raymond Auge <[email protected]> > 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. :) > Great! > > > > 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! Again, great! > 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. All the packages mentioned in the report are exported: e.g. (`bnd print ~/.m2/repository/org/apache/cxf/cxf-rt-bindings-soap/3.1.9/cxf-rt-bindings-soap-3.1.9.jar`): ... Export-Package org.apache.cxf.binding.soap {version=3.1.9} ... org.apache.cxf.binding.soap.interceptor {version=3.1.9} e.g. (`bnd print ~/.m2/repository/org/apache/cxf/cxf-core/3.1.9/cxf-core-3.1.9.jar`): ... Export-Package ... org.apache.cxf.databinding.stax {version=3.1.9} etc. > 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? It wasn't that there were actually problems caused, other than pure semantic compatibility issues as package dependencies expect semantic versioning. The failing baseline report was just a hint that there might be a problem. In fact the baseline report was accidentally generated due to a bug in our build. However, the report did not reflect well and caused a maintainability concern. It also would have potentially caused a fan out of compatibility issues and without the albeit _accidental_ baseline failure we would never have noticed. We're working through these issues given our better understanding of CXF now.. but let's just say it was unexpected. Sincerely, - Ray > 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 <[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) > > -- > 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)
