[
https://issues.apache.org/jira/browse/FELIX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483646
]
Stuart McCulloch commented on FELIX-262:
----------------------------------------
The bundle plugin has a @requiresDependencyResolution of RUNTIME (only COMPILE,
RUNTIME or TEST scopes are supported by Maven2 at the moment) which suggests
that PROVIDED dependencies won't be resolved before the plugin runs, and
therefore don't appear on the project's artifact list - this is confirmed when
I instrument the plugin.
If you change to use a RUNTIME scope, the dependency appears on the artifact
list retrieved by the plugin, but is filtered out by the plugin using the same
tests as in the maven project code (ie. only select COMPILE / SYSTEM / PROVIDED
scopes for the compilation classpath). So again, no jar.
My current solution for wrapping existing jars is to not use the normal
dependency mechanism, but configure the dependency plugin to copy the jars from
the repository to a known directory (lib) - I then use an Include-Resource
entry to embed the jar inside the OSGi bundle. The benefit of using the
dependency plugin directly is that you can ask it to exclude transitive
dependencies. This also has the added benefit that the embedded jars won't be
dragged along when you depend on the OSGi bundle. You can also make Eclipse
happy because a copy of the jar is in a local directory.
Example setup:
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<!--
default is one jar per bundle, but this can be overriden in
sub-projects
-->
<artifactItems>
<artifactItem>
<groupId>${jar.groupId}</groupId>
<artifactId>${jar.artifactId}</artifactId>
<version>${jar.version}</version>
</artifactItem>
</artifactItems>
</configuration>
<executions>
<execution>
<id>copy</id>
<phase>generate-resources</phase>
<goals>
<goal>copy</goal>
</goals>
<configuration>
<outputDirectory>lib</outputDirectory>
<excludeTransitive>true</excludeTransitive>
</configuration>
</execution>
</executions>
</plugin>
If you want to unpack the jar contents into target/classes then you can use the
unpack goal instead, or ask bnd to unpack it for you.
For a more complete example check out
https://scm.ops4j.org/repos/ops4j/projects/pax/build
> Scope of wrapped dependencies from felix commons
> ------------------------------------------------
>
> Key: FELIX-262
> URL: https://issues.apache.org/jira/browse/FELIX-262
> Project: Felix
> Issue Type: Improvement
> Components: Felix Commons
> Reporter: Alin Dreghiciu
>
> Most/Some (I did not check) wrapper bundles have the dependency to the
> wrapped library expressed without any <scope>. This means that it will be the
> default = COMPILE. Nothing wrong till here but by the moment that I will
> express a dependency on the wrapper = those from the felix commons, due to
> transitivity, will also pull the original wrapped library, fact that is not
> required since is already in the bundle.
> So, all the pom's must be changed to add a <scope>PROVIDED</scope> to all
> dependencies.
> If you need help let me know.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
