Compile scope is Maven means that the dependency is required at compile and runtime (it's a little bit of a misnomer), provided will also indicate that a dependency is needed at runtime, but it will already be present. With OSGi, this is a little confusing your bundle will still reference the jaxb version in the bundle and assume that version will already be dwployed. I understand why you would want to exclude dependency, but keep in mind that by excluding the dependency to get around a uses constraint, may cause a problem at runtime if that jaxb version isn't compatible with camel component. If you are hitting a usage constraint, then OSGi is giving you a warning the expected version isn't there. Excluding that knowledge from the bundle makes that depency jdk version dependent.
I would keep that in mine. The extra jaxb version isn't going to take up much space so I wouldn't worry about it being there if not used. Hopefully that makes sense and helps make sure you are making an informed decision to exclude the dependency. Ryan On Dec 8, 2014 7:07 AM, "MarkD" <[email protected]> wrote: > Ah ok. As far as this issue goes that shouldn't affect anything though, > right? > > The only downside I can see is the artifact (in this case jaxb-impl) will > be > packaged up in the repo wasting some space. > > The features file generated for the kar still seems to be used even when > using compile scope for a kar dependency in a karaf-assembly. > > This would explain why my jaxb problem went away when I discovered the > excludedArtifacts config option. > > > > -- > View this message in context: > http://karaf.922171.n3.nabble.com/Dependency-on-Camel-brings-in-a-jaxb-impl-that-causes-a-use-constraint-violation-tp4037029p4037048.html > Sent from the Karaf - User mailing list archive at Nabble.com. >
