2009/8/21 Richard S. Hall <[email protected]>
> 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.
>
another approach is to use the standard jar plugin to create the empty
bundle:
<build>
<plugins>
<plugin>
<artifactId>maven-jar-plugin</artifactId>
<configuration>
<archive>
<manifestEntries>
<Bundle-ManifestVersion>2</Bundle-ManifestVersion>
<Bundle-SymbolicName>${pom.artifactId}</Bundle-SymbolicName>
<Bundle-Version>${pom.version}</Bundle-Version>
<Export-Package>javax.activation,javax.servlet</Export-Package>
<Fragment-Host>system.bundle</Fragment-Host>
</manifestEntries>
</archive>
</configuration>
</plugin>
</plugins>
</build>
as the bundleplugin isn't actually adding much value in this use-case...
> -> 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]
>
>
--
Cheers, Stuart
