All,
One major impediment to converting a working application into an OSGi bundle is this thing called an unconstrained violation. From what I've read, if you get an unconstrained violation, and Karaf does not tell you what that violation was, figuring it out is a long and arduous process. This process involves ensuring all of the imports you use on your application do now conflict with imports your imported packages use. First off, is that a correct explanation? I think it is close, but not quite correct. It would seem to me, that writing a tool to figure out a given unconstrained violation should (while not trivial) shouldn't be a completely arduous task. Has there been thought given to creating a tool that would help to resolve unconstrained violations? A second question I have can best be presented by an example. My developers prefer Spring 3.0.2-RELEASE to 2.5.6-SNAPSHOP, and the dev's also use Camel. The Camel 2.2.0 features.xml file specifies the use of Spring 2.5.6.SNAPSHOT. My developers are currently using camel, AND Spring 3.0.2-RELEASE. As long as the version numbers of these products are clearly made available in Karaf (they are), this should not create an unconstrained violation, right? Ok, now to the real question, when hunting down unconstrained violations, should I be focusing on those bundle-imports who have no version numbers? The bundle "0" has no version in Karaf 1.6.0, could the use of other versions of say... javax.annotations be what is causing the unconstrained violation? v/r, Mike Van
