LOL Yes I did mean Ray I guess that is what I get for have all the
message headers collapsed so I could not see everyones name
Richard
On Mon, Nov 24, 2008 at 10:27 AM, Jeanfrancois Arcand
<Jeanfrancois.Arcand_at_sun.com> wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>