I don't think it is a big deal as long as we don't have conflicts. But
the split packages can cause issues for OSGi bundles if those packages
are exported.
So for instance if the Grizzly-Framework bundle and the
Grizzly-http-utils bundles both tried to export com.sun.grizzly.util
it would cause a issue. But If I remember correctly they both mark
those packages as private so no conflict
I'm most likly going to have to do the single unified bundle like
Salut did for the HttpService as well again mostly because I need to
get to some of those packages that are not exported.
Richard
On Mon, Nov 24, 2008 at 10:01 AM, Jeanfrancois Arcand
<Jeanfrancois.Arcand_at_sun.com> wrote:
> Thanks Richard for the hint!
>
> At least I've removed the warning for the bundle modules. But we stoll do
> have issue with split package amongst module. As an example, we do have:
>
> /grizzly/ -> com.sun.grizzly.util
> /http-utils/ -> com.sun.grizzly.util
>
> I'm not sure we can fix that without braking backward compatibility if we
> rename those packages.
>
> A+
>
> -- Jeanfrancois
>
>
> Richard Jackson wrote:
>>
>> 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
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>