Salut,
Richard Jackson wrote:
> 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
OK I will try to integrate 1.9.0 in GlassFish v3 directly using
OSGi...before the were repackaging so I will know for sure it that cause
problem or not.
>
> 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.'
Hahaha When I use 'Salut', it means 'hi' in French...it is not the name
:-) I think you means Ray here :-)
A+
-- jeanfrancois
>
> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>