FYI: I pointed Peter Kriens (the author of the Bnd-tool) to this
thread and this was his answer:
----------------------------------------
Well, you have to put the rt.jar on the classpath, then bnd can see
those classes. You can do this with <_classpath>rt.jar</_classpath>
However, I think creating a fragment with these classes is a VERY bad
idea. Many of those classes do not have a portable implementation,
they can use com.sun classes underneath or can even be bound to native
code. You will also have two copies then and very likely the classes
are automatically exported by the framework already. All the classes
you mention are already automatically added to the
org.osgi.framework.system.package.
For classes that are not in the JRE, just create (or reuse) standard
bundles, there is absolutely no reason to use fragments for this.
Using a JRE, you should use the Bundle-RequiredExecutionEnvironment.
Doing it in the way you suggest is bound to backfire except on
platforms that already have those classes ...
Kind regards,
Peter Kriens
----------------------------------------
Am 21.08.2009 um 16:36 schrieb Richard S. Hall:
Yeah, you are correct.
I have similar issues when trying to create test cases where I am
just faking a bundle. One thing I did to get around it is something
like this:
Include-Resource: bar/resource.txt; literal="BAR", foo/
resource.txt; literal="FOO"
So, I just create something in the bundle in the package I want to
export. This is a hack too.
-> richard
On 8/21/09 10:28, Daniel Bimschas wrote:
Hi Richard,
thanks for your answer. <_failok>true</_failok> simply lets bnd and
the maven plugin ignore that there were errors during the bundle
build process. But the "Export-Package" headers are still not
included as bnd knows they're not really supplied by the bundles'
contents. Therefore bnd doesn't put them into the generated
manifest file.
Checking the bnd documentation again, I found that I could use "-
manifest" to disable manifest generation and to use a prepared
manifest. But that would still be a suboptimal solution for me :-
( What would be perfect was an instruction marking the export as
"do it anyway", maybe something like "+javax.servlet", in analogy
to excluding packages with "!excluded.package".
Regards,
Daniel
Am 21.08.2009 um 15:38 schrieb Richard S. Hall:
I think you can use:
<_failok>true</_failok>
-> richard
On 8/21/09 4:19, Daniel Bimschas wrote:
Hi!
I try to generate a fragment bundle to "system.bundle", exporting
the JVM packages not visible at runtime, like javax.servlet.
Therefore, as the project bases on maven using maven-bundle-
plugin, I would like to generate the MANIFEST.MF, rather than
editing it by hand. However using the following instructions:
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<version>2.0.0</version>
<configuration>
<instructions>
<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
<Export-Package>javax.activation,javax.servlet</Export-Package>
</instructions>
</configuration>
</plugin>
i'll always get the following error:
[WARNING] Warning building bundle {...} : Instructions in Export-
Package that are never used: javax\.activation, javax\.servlet
[WARNING] Warning building bundle {...} : Superfluous export-
package instructions: [javax.servlet, javax.activation]
[WARNING] Warning building bundle {...} : Did not find matching
referal for *
While that is totally correct behaviour in the normal use cases,
I would nevertheless want to force the maven-bundle-plugin to
generate the MANIFEST whatsoever, putting Export-Package:
javax.servlet, ... inside.
Is there a way to do it? With maven-bundle-plugin?
Is there another way to get a grip on non-java.*-packages in the
runtime? I know of the "org.osgi.framework.system.package"
startup parameter. But I think that using the fragment bundle
approach is more elegant, as I'll be able to deploy my bundles in
any unconfigured newly downloaded OSGi runtime distro.
Kind regards,
Daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
----------------------
Daniel Bimschas
Fleischhauer Straße 45
23552 Lübeck
[email protected]
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
----------------------
Daniel Bimschas
Fleischhauer Straße 45
23552 Lübeck
[email protected]
----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
