Add OSGi headers to MANIFEST.MF

[GoogleCodeExporter]

It would be great to use Kryo inside an OSGi container like Eclipse, felix, 
knopplerfish, Glassfish, etc. In order to do so, the jar file's MANIFEST.MF 
needs additional headers describing how this library can be interacted with and 
what it depends on.

Fortunately this header can be automatically generated, usually via the Apache 
Felix Maven plugin. If interested I can create a patch with the necessary 
changes.

Original issue reported on code.google.com by m...@thebishops.org on 3 Jul 2013 at 7:24

[GoogleCodeExporter]

Attached is a patch to simplify the generation of OSGi headers in the manifest. 
Changes include:

1. Update Objenesis to 1.3, which has proper OSGi headers.
2. Fix up dependency embedding to not include objenesis any more.
3. Remove shade plugin as it doesn't appear to serve any purpose now that 
objenesis is not embedded.

Original comment by m...@thebishops.org on 9 Jul 2013 at 5:42

Attachments:

• #117_Better_OSGi_bundle_creation.patch

[GoogleCodeExporter]

Overall, better support for OSGI is definitely welcomed!
But it seems like your patch goes a bit too far, as far as I understand it:
It does not generate kryo-shaded anymore, or? And those people, who use kryo 
with alternative versions of ASM (or other libs used by Kryo) really need this 
shaded version of Kryo to avoid conflicts.

We need to find a way to generate multiple jars (shaded, non-shaded, etc) using 
a single POM file, if possible.

Any ideas how to achieve this?

Original comment by romixlev on 23 Jul 2013 at 1:45

[GoogleCodeExporter]

This is a fairly standard problem; most libs do not bundle or shade in their 
dependencies but let the consuming application make the choice as to which 
shared lib to use for a given interface. In OSGi, one would create a bundle 
that embeds the set together.

The problem with including ASM in kryo is that your bundle the provides the 
capability outward. This now puts a harder burden on someone who does not want 
your jar to provide these capabilities. It's harder to mask out than shade in. 

It aslo makes it harder to provide a newer version of the dependency. For 
instance I will want to use ASM 3.2 on JDK 7, but if kryo bundles an older 
version, I won't have a way to bind it to the newer, hopefully faster, version.

Original comment by m...@thebishops.org on 23 Jul 2013 at 2:57

[GoogleCodeExporter]

For all those that end up on this page while searching "kryo osgi" like me, 

remember to set up the classloader of the Kryo instance with the one of the 
bundle or Kryo will not be able to create your classes while deserializing.

For example you can do this by calling setClassLoader(...) after initialization 
of a Kryo instance:

Kryo kryo = new Kryo();
kryo.setClassLoader(getClass().getClassLoader());

Original comment by cristian...@gmail.com on 28 Aug 2013 at 11:30

[GoogleCodeExporter]

@matt: We've just released kryo 2.22, the main jar is now replaced with the 
shaded jar (classes from included jars are renamed/relocated), as users 
regularly had issues with a conflicting asm version.

Do you see possible improvements regarding the currently generated manifest?

Original comment by martin.grotzke on 1 Oct 2013 at 7:22

[GoogleCodeExporter]

Thanks for pinging me.  I'll have a look in a couple of weeks as I am unable to 
look at it now.

Original comment by m...@thebishops.org on 3 Oct 2013 at 4:25

[GoogleCodeExporter]

I've had some time today to work on this issue this weekend. From my reading of 
your goals you would rather have all your dependencies embedded in the kryo jar 
rather than have them come in from the classpath. This is why the shade plugin 
is used and you are attempting to use the Embed-Dependency plugin.

Is this a correct assumption? Or, are you willing to allow the Objenesis jar to 
come in via the classpath?

Original comment by m...@thebishops.org on 5 Oct 2013 at 4:24

[GoogleCodeExporter]

It looks like shading and OSGi are not going to get along very well because the 
shade plugin runs after the bundle plugin. Bundle plugin looks through classes/ 
for dependencies to create a manifest for.

I see two options:

1. Don't shade Objenesis.jar but require it on the classpath.
2. Manually define the manifest headers and use the shade plugin's 
ManifestResourceTransformer to add the correct manifest headers to the shaded 
jar. This means not using the maven-bundle-plugin at all.

I would prefer #1 as it would be more robust over time as the Kryo API changes 
over time. The Bundle plugin will keep the manifest headers up to date.

Either option will likely still require a bit more work defining 
<Private-Package> entries for the other shaded packages too.

Original comment by m...@thebishops.org on 6 Oct 2013 at 7:41

[GoogleCodeExporter]

@matt Issues have moved to github: 
https://github.com/EsotericSoftware/kryo/issues/117
Can we continue there?

Original comment by martin.grotzke on 13 Nov 2013 at 11:57