felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stuart McCulloch (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-899) Version attribute missing from Import-Package on provided dependencies
Date Sun, 25 Jan 2009 15:26:59 GMT

    [ https://issues.apache.org/jira/browse/FELIX-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667093#action_12667093

Stuart McCulloch commented on FELIX-899:

IMHO the same classpath used to compile the project should be passed to BND. However, this
appears to be harder than it should be in Maven because of the way it lazily discovers transitive
dependencies (as this is computationally expensive). Maven provides a mojo setting for plugins
that forces resolution of project dependencies to a certain scope phase (@requiresDependencyResolution).
Without this setting a plugin gets the same dependency resolution as the previous plugin in
the build, which could vary a lot depending on what plugins are configured in your POM.

Historically, @requiresDependencyResolution has always been set to "runtime" in the bundleplugin
- which means that all compile and runtime dependencies will be resolved. Unfortunately this
means that provided dependencies won't be resolved, and therefore won't be passed onto BND
(see the note at the top of the bundleplugin docs: http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html).

For some weird reason Maven doesn't let you set @requiresDependencyResolution to "provided",
which would be the obvious choice, but I've been looking into setting it to "test". This would
bring in the complete classpath, but could break projects that depend on the original reduced
classpath, which is why I've not yet made this change to 1.5.0-SNAPSHOT (although it is definitely

FYI changing over to use "getDependencyArtifacts()" is definitely not a good idea, as this
only provides *direct* project dependencies. It completely ignores any transitive dependencies.
So while it works for your test POM, it would break most of the other POMs out there that
rely on having the current transitive classpath.

> Version attribute missing from Import-Package on provided dependencies
> ----------------------------------------------------------------------
>                 Key: FELIX-899
>                 URL: https://issues.apache.org/jira/browse/FELIX-899
>             Project: Felix
>          Issue Type: Bug
>          Components: Maven Bundle Plugin
>         Environment: Maven version: 2.0.9
> Java version: 1.6.0_11
> OS name: "linux" version: "2.6.25-gentoo-r7" arch: "amd64" Family: "unix"
>            Reporter: Brian Atkinson
>         Attachments: projects.tar.bz2, projects2.tar.bz2
> I have been using and testing out the maven-bundle-plugin-1.5.0-20081205.125536-1 (SNAPSHOT)
and ran across what I believe is a bug.
> Suppose there is a project a:a:1.0.0-SNAPSHOT.  This project has a single class: a.a.A.
 The bundle plugin has the following instructions:
> <instructions>
> 	<_versionpolicy>[$${version;===;${@}},$${version;=+;${@}})</_versionpolicy>
> 	<Bundle-RequiredExecutionEnvironment>JavaSE-1.6</Bundle-RequiredExecutionEnvironment>
> 	<Export-Package>$${replace;${Bundle-SymbolicName};\W;.}.*;version=${project.version}</Export-Package>
> </instructions>
> This results in an Export-Package line of:
> Export-Package: a.a;version="1.0.0.SNAPSHOT"
> So far so good.  Now suppose there is a project b:b:1.0.0-SNAPSHOT.  This project depends
on a:a:1.0.0-SNAPSHOT (scope: provided) and the project also has a single class b.b.B which
extends a.a.A.  The maven-bundle-plugin is given the same instructions as project a:a above.
 The resulting Import-Package line is:
> Import-Package: a.a,b.b;version="[1.0.0,1.1)"
> This is not what is expected.  What is expected is the following:
> Import-Package: a.a;version="[1.0.0,1.1)",b.b;version="[1.0.0,1.1)"
> Digging into the code I found that in org.apache.felix.bundleplugin.BundlePlugin (trunk
rev: 723704) in function "protected Jar[] getClasspath( MavenProject currentProject ) throws
ZipException, IOException" line 708 reads:
> final Collection artifacts = getSelectedDependencies( currentProject.getArtifacts() );
> When the plugin is running "currentProject.getArtifacts()" returns an empty set.  This
then causes the classpath not to be set properly when calling BND (none of the dependencies
are available for reading their manifests).  I changed the line to use "currentProject.getDependencyArtifacts()"
and the manifest for b:b was correct.
> I am going to attach a file with two very simple projects which mirror what I have described

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message