You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Alin Dreghiciu (JIRA)" <ji...@apache.org> on 2007/03/23 10:04:32 UTC
[jira] Created: (FELIX-262) Scope of wrapped dependencies from
felix commons
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.
[jira] Commented: (FELIX-262) Scope of wrapped dependencies from
felix commons
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (FELIX-262) Scope of wrapped dependencies from
felix commons
Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483973 ]
Alin Dreghiciu commented on FELIX-262:
--------------------------------------
That's the same approach used for sping-osgi but with the osgi plugin.
I agree that can be an work around or even a better approach if we would like to keep maven-bundle-plugin at a minimum but to me looks verbose.
Not very sure about the following but you will have to add the dependencies anyhow to your pow because otherwise those dependencies will not be pulled into the local repo for the dependency plugin. And then again you will have to mark them as provided if you do not want them as transient dependency (back to the original problem)
> 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.
[jira] Commented: (FELIX-262) Scope of wrapped dependencies from
felix commons
Posted by "Carlos Sanchez (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484012 ]
Carlos Sanchez commented on FELIX-262:
--------------------------------------
i don't see the scope as the solution, is a workaround, it's not designed to do that
there are two cases here:
- bundle = original library + OSGi manifest
I think this is the best solution, if you do it from the original library pom, you just need the bundle:manifest goal, if you do it from outside somehow you should deploy the dependencies section from the pom in the original library instead of the current one.
- bundle = several libraries
this will require http://jira.codehaus.org/browse/MNG-2316 to be implement first to list all the dependencies provided by the bundle
> 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.
[jira] Commented: (FELIX-262) Scope of wrapped dependencies from
felix commons
Posted by "Stuart McCulloch (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484004 ]
Stuart McCulloch commented on FELIX-262:
----------------------------------------
If you specify the above snippet in the pluginManagement section of the parent pom then you only need to specify three property values in the child pom:
<properties>
<jar.artifactId>servlet-api</jar.artifactId>
<jar.version>2.5</jar.version>
<jar.groupId>javax.servlet</jar.groupId>
</properties>
and also include the dependency plugin in the build list for the child pom (this approach also avoids problems with plugin inheritance):
<build>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
</plugin>
... etc ...
and the specified artifacts will get pulled into the local repo by the dependency plugin, even though they're not in the usual dependency list.
If you need to wrap more than one jar into the bundle then you just need to amend the artifact list in the child pom (this example is for the asm bundle) :
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<configuration>
<artifactItems>
<artifactItem>
<groupId>${jar.groupId}</groupId>
<artifactId>${jar.artifactId}</artifactId>
<version>${jar.version}</version>
</artifactItem>
<artifactItem>
<groupId>${jar.groupId}</groupId>
<artifactId>${jar.artifactId}-commons</artifactId>
<version>${jar.version}</version>
</artifactItem>
</artifactItems>
</configuration>
</plugin>
( for a working example checkout the url given above - mvn install, then go to a temp folder and run the SIMPLE_OSGI_PROJECT.sh script )
> 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.
[jira] Commented: (FELIX-262) Scope of wrapped dependencies from
felix commons
Posted by "Alin Dreghiciu (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483495 ]
Alin Dreghiciu commented on FELIX-262:
--------------------------------------
Well, I checked out but the scope stuff seams not to work. maven bundle plugin will not pull the dependency in this case. I'm checking out why and let you know. Does anyone else know so it will save me some time?
> 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.