Ok Found the issue you can get rid of the warning message by using a
BND directive.
The warnings are actually due to the private package com.sun.grizzly.*
in the pom
the maven-bundle-plugin uses BND to do all the actual work of building
the bundle and it states:
Bnd traverse the packages on the classpath and copies them to the
output based on the instructions given by the Export-Package and
Private-Package headers. This opens up for the possibility that there
are multiple packages with the same name on the class path. It is
better to avoid this situation because it means there is no cohesive
definition of the package and it is just, eh, messy. However, there
are valid cases that packages should be merged from different sources.
For example, when a standard package needs to be merged with
implementation code like the osgi packages sometimes (unfortunately)
do. Without any extra instructions, bnd will merge multiple packages
where the last one wins if the packages contain duplicate resources,
but it will give a warning to notify the unwanted case of split
packages.
The above may be why the example I saw for doing this merged the
source tree then built the bundle so that there would be a single
unified or cohesive definition of the packages.
So BND has issued the warning that our dependent jar's have
split-packages but went ahead and merged them any ways using the
default of the last defined resource found will be included (I've
looked and the Grizzly packages do not have conflicts so nothing got
left out)
Just change this part of your POM
<Private-Package>
!com.sun.grizzly.tcp,
!com.sun.grizzly.http,
!com.sun.grizzly.util.buf,
!com.sun.grizzly.util.http,
!com.sun.grizzly.tcp.http11,
com.sun.grizzly.*;-split-package:=merge-first <------ The change
</Private-Package>
The directive "-split-package:=merge-first" basiclly means Yea I know
I have split packages so don't give me warnings about that but do give
me a warning if there is a conflict And in the case of a conflict the
first resource wins. This can be changed to merge-last which means the
last resource found wins for the inclusion.
Hope that helps
Richard
On Sat, Nov 22, 2008 at 6:44 AM, Ray Racine <ray.racine_at_gmail.com> wrote:
> One thing I do is build my own monolithic Grizzly from the constituent jars.
> I embed the Grizzly with a customer Adapter in my project and I needed some
> stuff which was not exported from the pre-built Grizzly bundles.
>
> The following Maven2 POM fetches the Grizzly jar set and builds a
> mono-bundle/jar which has the added advantage of a one bundle install in
> Felix.
>
> I do get split package warnings when building the mono-bundle.
>
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd">
> <modelVersion>4.0.0</modelVersion>
>
> <groupId>sun.com.sun.grizzly</groupId>
> <artifactId>grizzly</artifactId>
> <packaging>bundle</packaging>
> <version>${grizzly.version}</version>
> <name>OSGi Grizzly - Sun</name>
> <url>http://github.com/GreyLensman/crank/tree/master</url>
>
> <properties>
> <grizzly.version>1.8.6.1</grizzly.version>
> </properties>
>
> <repositories>
>
> <repository>
> <snapshots>
> <enabled>true</enabled>
> </snapshots>
> <id>java.net</id>
> <name>Sun's Java Net Maven2 Repository</name>
> <url>http://download.java.net/maven/2</url>
> <layout>default</layout>
> </repository>
>
> </repositories>
>
> <dependencies>
>
> <dependency>
> <groupId>com.sun.grizzly</groupId>
> <artifactId>grizzly-framework</artifactId>
> <version>${grizzly.version}</version>
> </dependency>
>
> <dependency>
> <groupId>com.sun.grizzly</groupId>
> <artifactId>grizzly-http</artifactId>
> <version>${grizzly.version}</version>
> </dependency>
>
> <dependency>
> <groupId>com.sun.grizzly</groupId>
> <artifactId>grizzly-rcm</artifactId>
> <version>${grizzly.version}</version>
> </dependency>
>
> <dependency>
> <groupId>com.sun.grizzly</groupId>
> <artifactId>grizzly-http-utils</artifactId>
> <version>${grizzly.version}</version>
> </dependency>
>
> <dependency>
> <groupId>com.sun.grizzly</groupId>
> <artifactId>grizzly-portunif</artifactId>
> <version>${grizzly.version}</version>
> </dependency>
>
> </dependencies>
>
> <build>
>
> <plugins>
>
> <plugin>
> <groupId>org.apache.felix</groupId>
> <artifactId>maven-bundle-plugin</artifactId>
> <extensions>true</extensions>
> <configuration>
> <instructions>
> <Export-Package>
> com.sun.grizzly.tcp,
> com.sun.grizzly.http,
> com.sun.grizzly.util.buf,
> com.sun.grizzly.util.http,
> com.sun.grizzly.tcp.http11
> </Export-Package>
> <Private-Package>
> !com.sun.grizzly.tcp,
> !com.sun.grizzly.http,
> !com.sun.grizzly.util.buf,
> !com.sun.grizzly.util.http,
> !com.sun.grizzly.tcp.http11,
> com.sun.grizzly.*
> </Private-Package>
> </instructions>
> </configuration>
> </plugin>
>
> </plugins>
> </build>
> </project>
>
> R.
>
>
>
> On Fri, Nov 21, 2008 at 11:46 PM, Richard Jackson
> <richard.jackson_at_gmail.com> wrote:
>>
>> I think as long as you don't export the same package/class you are ok
>> in OSGi but I will take a look as well. As The question made me
>> curious. I've been reading the spec (but mostly looking at the
>> HTTPService spec section).
>>
>> Richard
>>
>> On Fri, Nov 21, 2008 at 4:50 PM, Jeanfrancois Arcand
>> <Jeanfrancois.Arcand_at_sun.com> wrote:
>> > Salut,
>> >
>> > Oleksiy Stashok wrote:
>> >>
>> >> Hi guys,
>> >>
>> >> what about repackaging issue, which we have currently for OSGi GF
>> >> integration? If I understand correctly, different Grizzly OSGi modules
>> >> shold
>> >> not export same packages?
>> >> Shouldn't we fix this first before doing other steps?
>> >
>> > I think only GF suffer that problem (not sure why). I was able to load
>> > Grizzly's module with Felix without any issues. I need to investigate
>> > more...
>> >
>> > A+
>> >
>> > -- Jeanfrancois
>>
>
>