[
https://issues.apache.org/jira/browse/FELIX-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667577#action_12667577
]
luke w patterson commented on FELIX-899:
----------------------------------------
Stuart wrote: "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..."
I'm certainly not trying to question anyone's competency/judgement. I'm just
trying to fully understand the dilemma at hand. I'm interested in the future
behavior because I hope to start using this plugin in my projects.
I tend to agree with your view that
"IMHO the same classpath used to compile the project should be passed to BND."
I don't understand why that goal isn't reachable. Please correct me if I'm
wrong, it seems you want the same thing that maven-compiler-plugin passes to
javac. (i.e. compile is included, runtime is excluded, direct provided is
included, transitive provided is excluded) Is that correct?
Also, I don't understand this code from BundlePlugin:
714 : if ( Artifact.SCOPE_COMPILE.equals( artifact.getScope() )
715 : || Artifact.SCOPE_SYSTEM.equals( artifact.getScope() )
716 : || Artifact.SCOPE_PROVIDED.equals( artifact.getScope() ) )
717 : {
718 : File file = getFile( artifact );
719 : if ( file == null )
720 : {
721 : getLog().warn(
722 : "File is not available for artifact " + artifact + " in project "
723 : + currentProject.getArtifact() );
724 : continue;
725 : }
If the artifact file is null, it seems like it would be better to
programmatically request resolution and fail build if it can't be resolved. I
think you could safely consider an unresolvable dependency to be an error.
> 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.
