[
https://issues.apache.org/jira/browse/FELIX-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667558#action_12667558
]
Stuart McCulloch commented on FELIX-899:
----------------------------------------
Brian - this check matches the core Maven code that assembles the compilation
classpath artifacts (see getCompileArtifacts in MavenProject.java) because
runtime artifacts by definition aren't used for compilation. So it's
technically correct, but because of the complex interaction between this check
and the lazy dependency I mentioned previously it means just compile (or
default) and system scope artifacts currently reach BND. (ie. the docs
shouldn't list runtime)
However, I'm also considering passing *all* jars to Bnd so it has the complete
set of dependency information - the lack of these jars mostly means BND has a
reduced set of version information, but it also stops people from inadvertently
pulling in all sorts of classes when they use "Export-Package: *" and expect
that to only include compile dependencies (which is why I discourage people
from setting it to *).
The focus of the current release is all about sorting this out, while trying
not to break too many projects - as well as making more jars available to BND,
I'm also planning on improving the default settings so that just changing a
project from "jar" to "bundle" packaging will result in the same content inside
the final bundle.
Luke - I have a fairly good grasp of Maven internals and have written various
code to get transitive dependencies before when I couldn't rely on the default
resolution rules. The problem isn't that we don't know what to do, we've just
been waiting for the right time in development to make this breaking change.
Actually this might turn out to be a 2.0.0 release, just to stress to people
that there are major changes to how the bundleplugin processes the 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
> Fix For: maven-bundle-plugin-1.6.0
>
> 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 here.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
