felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niclas Hedhman (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-899) Version attribute missing from Import-Package on provided dependencies
Date Sat, 24 Jan 2009 08:27:59 GMT

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

Niclas Hedhman commented on FELIX-899:

I disagree that BND should "guess" the Import package version ranges. I think there is no
"normal case". For you above, being a user of a.A has a very narrow version range due to the
subclassing, but in many use cases a much wider version range are expected to work, and still
yet for some projects even the exact dot dot release are needed. Unless you know the policies
of the project, it is hard to predict a range that will actually work.

I think that there are some discussions going on in the OSGi community to formalize the range
expectations, but right now, with all the third-party stff being bundlized, I think this feature
will be more harming than helping.

> 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
> 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