Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Message-ID: <602560772.1233037259521.JavaMail.jira@brutus>
Date: Mon, 26 Jan 2009 22:20:59 -0800 (PST)
From: "luke w patterson (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Subject: [jira] Commented: (FELIX-899) Version attribute missing from
 Import-Package on provided dependencies
In-Reply-To: <201258242.1232780399854.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

luke w patterson commented on FELIX-899:
----------------------------------------

Good to know.  I would never have imagined bnd would find useful information from the runtime-only deps.

"Now because Bnd can detect certain indirect uses of packages, it could add imports for code that you don't need at compile time but would need at runtime"

I'm trying to imagine an example of that.  (I probably just don't understand all the scenarios where it would add imports)  My guess is that it would be for the situation where a class was interacted with exclusively through reflection.  If that's the case, on the Maven side the runtime dep is considered to be "required" anyway so I wonder why it wouldn't just be directly coded to instead of through reflection.  Like I said, I must be missing some fundamental background information in this area.


Where did you learn those finer details of what bnd is capable of?  I tried the usual, the bnd homepage, but it didn't explain exactly which scenarios package imports would and wouldn't be auto-detected.


Thanks,

Luke

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