On Thursday, May 10, 2012 07:42:28 PM Babak Vahdat wrote: > Am 10.05.12 16:41 schrieb "Claus Ibsen" unter <claus.ib...@gmail.com>: > >On Thu, May 10, 2012 at 4:27 PM, Daniel Kulp <dk...@apache.org> wrote: > >> Not sure about this commit.... > >> > >> This commit would make this area of the code NOT work at all with CXF > >>2.5.x > >> and older. I'm personally OK with that since 2.10 is primarily tested > >>with > >> 2.6, but I'm not sure if that's the ideal situation. If it is, then > >>the > >> OSGi import ranges for CXF need updating as well to reflect that. > > > >Yeah if we can support both CXF 2.5 and 2.6 at the same time in Camel > >2.10 then that would be great. > > I don't really agree on this! > > How can we *seriously* claim that? Who does on a regular basis do run the > tests against both the CXF versions X & X+1 after each change by this > component > to make sure we're compatible with the both versions. The release notes > says on > which *exact* version of CXF this release (Camel 2.10) is based on.
In the integration space, we kind of have to expect and support various levels of integration with various technologies. Different users will be trying to integrate with different versions of things and may have different requirements about when they can "upgrade" certain things. If it's POSSIBLE to make that easier for them without too much trouble, that's likely not a bad thing. In some cases, we can provide support and testing out of the box. In other cases, we need to rely on the community to help us with that. It's quite possible that a user needs to upgrade to 2.10 for a particular new component, but cannot upgrade to CXF 2.6 yet due to some of the migration issues involved with that. (see the migration guide: http://cxf.apache.org/docs/26-migration-guide.html ) In this particular scenario, it kind of works both ways. As an example, Camel 2.9.2 "out of the box" uses CXF 2.5.x as 2.5.x was the version that was available and promoted when the 2.9.x branch was started. However, I KNOW Talend spent a ton of resources and time to make sure 2.9.2 was extremely well tested with CXF 2.6.0. For *OUR* users and customers, it made sense to have Camel 2.9.x and CXF 2.6.0 together so we spent quite a bit time testing that scenario. (another side effect of that was to make sure CXF 2.6.0 is quite back words compatible and migration issues were well document and thus helped the CXF community) So just because a particular version of Camel uses a particular version of CXF doesn't mean we should lock out others unless it makes sense to do so. Anyway, thanks for reverting that. Dan > IMHO > in a > non-OSGi (JAR-Hell) World we should be *very* strict about versioning, as > that's > also what Maven is all about: "Transitive Dependency Management" as you > simply > don't have any other way to go other than being absolutley *strict* that > "mvn dependency:tree" does *not* report any conflict, etc., etc. We all > have seen > the other side of the coin if we would not respect the versioning enough: > NoSuchMethodError, NoSuchFieldError, AbstractMethodError, etc. > > In the OSGi world however a bundle can claim to be dependent on a given > range of > some other bundles in the range of [X, X+Y) *no matter* which *exact* > version > in this range has been given at the runtime! Well to me this's an > unbelievable > magic of OSGi I have not understood til today! Sincerly how can a piece of > software > *seriously* claim/guarantee such a behavior. > > >There are people who put together their own choices, and dont go with > >the latest and greatest. > > IMHO these people are doing wrong and do take a big risk for no good > price! If > there's any reason why they can not upgrade part of the dependency chain, > then > to me it *not* the right time to upgrade at all, so that they should > better wait > Until the time is mature enough for a *serious* upgrade of the whole > dependency > chain. > > That all said, I did already revert that commit and do thank you both for > your > feedback. > > Babak -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
