osgi: convert all modules into bundles, ensure no package split

[carrot-garden]

see
#867 (comment)

[carrot-garden]

also note that current dependencies are wrong in
https://github.com/netty/netty/blob/master/all/pom.xml

1. there is no reason to carry "example" module in osgi bundle

    <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>netty-example</artifactId>
      <version>${project.version}</version>
      <scope>compile</scope>
      <optional>true</optional>
    </dependency>

2. should not depend on org.osgi or change scope to provided

    <dependency>
      <groupId>org.osgi</groupId>
      <artifactId>org.osgi.core</artifactId>
      <scope>compile</scope>
      <optional>true</optional>
    </dependency>
    <dependency>
      <groupId>org.osgi</groupId>
      <artifactId>org.osgi.compendium</artifactId>
      <scope>compile</scope>
      <optional>true</optional>
    </dependency>

[carrot-garden]

part of suggested osgi review #876

[carrot-garden]

instructions how to use bnd
http://www.aqute.biz/Bnd/Bnd

how to detect/report package split

If you put all bundles on the classpath and then do Private-Package: * it should report any split packages to you:


    findsplit.bnd:
    -classpath: ${lsa;jar/*}
    Private-Package: *

    $ bnd findsplit.bnd

You probably have to parse the output since the error is, as I recall, repeated rather loudly ...

Kind regards,

    Peter Kriens

[normanmaurer]

@trustin @carrot-garden that is something we really need to do before beta1 as we may need to juggle a few classes / packages

[carrot-garden]

I can convert all modules into bundles now. should I?

[trustin]

Is there a way to test this reliably as a part of the build?

[trustin]

If so, let's do that. Otherwise, isn't it OK to make only the all-in-one JAR an OSGi bundle?

[carrot-garden]

1. "way to test this reliably" - yes
2. "make only the all-in-one" - this would force extra dependencies and extra footprint

[trustin]

If yes, let's make all artifacts OSGI bundles (except for the all-in-one jar) with proper testing built into the build. Will you take on it, @carrot-garden ?

[trustin]

If you are busy, only testing part should be fine. I can handle from there.

[carrot-garden]

re "will you take on it" - ok.

[trustin]

Awesome. Thanks @carrot-garden!

[carrot-garden]

2 show stoppers so far:

1. transport-rxtx
   FIXME find/make osgi bundle for org.rxtx:rxtx

2. netty-common
   io.netty.util.internal is "internal" but used directly by bunch of other modules.
   options:
   a) make not "internal"
   b) keep "internal", but expose features via public factories, etc.

[normanmaurer]

I think keep them in internal is ok.. maybe we should have a package-list.info which tells that this package has stuff for "core" internal usage..

Am 01.02.2013 um 12:59 schrieb Andrei Pozolotin notifications@github.com:

2 show stoppers so far:

1. transport-rxtx
   FIXME find/make osgi bundle for org.rxtx:rxtx

2. netty-common
   io.netty.util.internal is "internal" but used directly by bunch of other modules.
   options:
   a) make not "internal"
   b) keep "internal", but expose features via public factories, etc.

—
Reply to this email directly or view it on GitHub.

[normanmaurer]

And I think for 1) it is not "our" problem. If someone wants to use it in osgi he needs to find the bundle or make it.

[carrot-garden]

rxtx: filed couple issues
http://code.google.com/p/create-lab-commons/issues/list

[carrot-garden]

rxtx: removed from osgi framework test
64f3455

[normanmaurer]

What about split packages, are we ok here?

Sent from my iPhone. Excuse any typos....

Am 01.02.2013 um 19:19 schrieb Andrei Pozolotin notifications@github.com:

rxtx: removed from osgi framework test
64f3455

—
Reply to this email directly or view it on GitHub.

[carrot-garden]

re: "split packages" - currently there are no split packages.
this is enforced by new module
https://github.com/netty/netty/pull/1010/files#diff-28

[carrot-garden]

rxtx: filed few issues
http://bugzilla.qbang.org/show_bug.cgi?id=201
http://bugzilla.qbang.org/show_bug.cgi?id=202

[carrot-garden]

re: "keep them in internal is ok"
in osgi, packages like ".internal." and ".impl." by convention are made private (not exported via manifest)
options:
a) rename "internal" to something else
b) override convention, include "internal" in manifest export

[carrot-garden]

re: "internal" - I would rather have them public.
currently I must have duplicate dependency since I need JZlib,
and io.netty.util.internal.jzlib supposed to be "the correct one".

[carrot-garden]

re: "jzlib" - how about making jzlib into a separate module: netty-jzlib
and work with jcraft to fix what we want them to fix?
then not much left of "internal".

[normanmaurer]

Well we could also move it to the codec

Sent from my iPhone. Excuse any typos....

Am 01.02.2013 um 19:57 schrieb Andrei Pozolotin notifications@github.com:

re: "jzlib" - how about making jzlib into a separate module: netty-jzlib
and work with jcraft to fix what we want them to fix?
then not much left of "internal".

—
Reply to this email directly or view it on GitHub.

[carrot-garden]

re: "jzlib" - filed issue ymnk/jzlib#8

[carrot-garden]

re: "netty-jzlib" - this module should use standard jcraft package name space
so when ymnk/jzlib#8 resolved it is a drop in replacement

[dantran]

btw, it is best to use karaf 2.3.1-SNAPSHOT for osgi validation:

1. It is in release path in the next week or 2.
2. karaf-3.0 release may take much longer

[carrot-garden]

re: "karaf version"
JB promised "something like one week" for v 3.0.0.RC1
http://mail-archives.apache.org/mod_mbox/karaf-user/201301.mbox/%3C50F88A8F.8030606@nanthrax.net%3E

[normanmaurer]

I think there is no need for an extra module... @trustin why you forked it ?

Sent from my iPhone. Excuse any typos....

Am 01.02.2013 um 20:07 schrieb Andrei Pozolotin notifications@github.com:

re: "netty-jzlib" - this module should use standard jcraft package name space
so when ymnk/jzlib#8 resolved it is a drop in replacement

—
Reply to this email directly or view it on GitHub.

[trustin]

There was no gzip support when I use jzlib.

[trustin]

It's pretty small and mature, so I'm not sure it is worth unforking.

[normanmaurer]

So let us just keep them as they are..

Sent from my iPhone. Excuse any typos....

Am 02.02.2013 um 11:24 schrieb Trustin Lee notifications@github.com:

It's pretty small and mature, so I'm not sure it is worth unforking.

—
Reply to this email directly or view it on GitHub.

[carrot-garden]

re "let us just keep them as they are" - you mean export "internal" as public package?

[normanmaurer]

Yes

Sent from my iPhone. Excuse any typos....

Am 02.02.2013 um 17:37 schrieb Andrei Pozolotin notifications@github.com:

re "let us just keep them as they are" - you mean export "internal" as public package?

—
Reply to this email directly or view it on GitHub.

[carrot-garden]

re: "internal" - made into public package 124044e

[carrot-garden]

@normanmaurer time to invite David Bosschaert #876.
one way to review would be:

cd /tmp
git clone git@github.com:netty/netty.git
cd netty
git checkout osgi-bundles
mvn clean install

then use bnd command line
to verify all jars for osgi compliance in */target of these projects:

netty-buffer
netty-codec
netty-codec-http
netty-codec-socks
netty-common
netty-handler
netty-transport
netty-transport-rxtx
netty-transport-sctp
netty-transport-udt

finally take a look on all "verify" projects

netty-verify

[normanmaurer]

complete

[carrot-garden]

@lw346

Luke:

since you seems be interested in rxtx, do you think you could move these forward:
(see above)
http://bugzilla.qbang.org/show_bug.cgi?id=201
http://bugzilla.qbang.org/show_bug.cgi?id=202

thanks
Andrei.

[lw346]

This would involve changing the build process of RXTX to something not-insane, and I think extends beyond my ken.

[carrot-garden]

:-)

do you know who could take on this?

here is example how I build udt
https://github.com/barchart/barchart-udt/tree/master/barchart-udt-core

I could provide basic project setup for rxtx similar to udt, but someone needs to finish