On Tue, 2006-12-05 at 15:49 +0100, Peter Kriens wrote: > I am not a maven expert so maybe there are better ways to do it. > > I never understood "provided" to mean include? If that is the > definition I can automatically include them. Can someone point me to > the relevant literature? Provided means that the jar is provided or available (somehow - like another bundle in the felix framework) at runtime.
Although the maven doc says: "provided - this is much like compile, but indicates you expect the JDK or a container to provide it. It is only available on the compilation classpath, and is not transitive." <tangent not-the-main-point-I-want-to-make="but just thought of it"> Now this can't be right, if you think about it anything scoped as provided would have to be available on maven's compilation, AND test AND run classpaths as well. (How else could you test your project?) </tangent> The Problem I really wanted to point out ----> When using the old OSGi plugin it was necessary to ALWAYS specify the scope 'provided' for any dependency, (let's call it depx that were/are bundles themselves and would be 'provided' at runtime) to prevent them from being embedded into the bundle (bundleA) along with their 'compile' scoped siblings. Unfortunately there is a side effect to using the scope element to determine the embedding of jars into the bundle. With provided, Maven no longer tags the artifact (depx) as transitive to bundleA, and thus other maven projects that now use the newly built/artifact bundleA as a dependency have lost transitive 'sight' of that depx. Oops! So is it possible to allow compile and provided scoped dependencies to be included or not included in the bundle? If so we can offer the community an OSGi bundling plugin without sacrificing maven's transitive dependency functionality. cheers, John
