Jetty and Pax Web karaf features versioning issues

[Denis Jouvin]

Hi all,

I'm trying to integrate Fuse Fabric features (the basic ones, namely: fabric-{zookeeper, core, commands, boot-commands, configadmin, jaas, agent, maven-proxy, zookeeper-commands} to the 5.0.0 ServiceMix distribution.

While solving some missing dependencies issues, I was faced with a problem regarding the Pax Web and Jetty features : the problem comes from the fact that between version 7.5.4 and 7.6+, Jetty refactored out their security package and, by doing so, changed their API by renaming some packages, like org.eclipse.jetty.http.security which is now org.eclipse.jetty.util.security.

By doing so they violated the semantic versioning contract and broke compatibility, but I'm not sure Jetty is initially tied to such rules.

The problem is that the dependencies expressed in the Karaf features, used by Fuse Fabric (see for exemple standard-2.3.0.redhat-60024-features.xml or standard-2.2.5.fuse-70-097-features.xml) don't really take into account this compatibility gap :
- Pax Web feature declares a dependecy to Jetty feature like this: <feature version="[7.0,8.0)">jetty</feature>
- however the Jetty feature may be bound to either Jetty 7.5.4 or Jetty 7.6.7, which are incompatible due to the renaming of the packages.

When trying to integrate Fuse Fabric to ServiceMix, this results in a missing package import (for org.eclipse.jetty.util.security).

I think the version range of the Pax Web import should be modified to [7.0, 7.6) for Karaf version "2.2.5.fuse-70-097" and less, and to the range [7.6, 8.0) for the version "2.3.0.redhat-60024" and more).

I am afraid to run into the same kind of problems since RedHat JBoss Fuse versions (of Karaf and Fuse Fabric) are not really "aligned" with community version of Karaf and ServiceMix.

Generally speaking, should we consider that Fuse and Karaf feature versions are mainly "indicative" and that features definitions should not be used outside the configuration/snapshot for which they have been designed, or should we consider that they have the same semantic value as, say, OSGi bundle level dependencies.

Denis Jouvin.

[Ioannis Canellos]

Good catch!

I'd say that the feature ranges indicate the expectation. But it is
possible that if the underlying project doesn't follow the semantic
versioning to run into problems like the one you discovered.

> --
> You received this message because you are subscribed to the Google Groups
> "fusefabric" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to fusefabric+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel