Clean up OSGi metadata #60

ctron · 2016-10-11T14:41:49Z

This change does remove "sun.misc" and "sun.nio.ch" from the list of
imported packages.

Signed-off-by: Jens Reimann jreimann@redhat.com

This change does remove "sun.misc" and "sun.nio.ch" from the list of imported packages. Signed-off-by: Jens Reimann <jreimann@redhat.com>

kevinherron · 2016-10-11T20:32:45Z

Should we fix the duplicate package export as well? This commit just cleans up the imports.

ctron · 2016-10-12T07:36:20Z

I will. I just thought I will start with the easier one 😉

Signed-off-by: Jens Reimann <jreimann@redhat.com>

kevinherron

Changing the packaging type to 'bundle' and relying on the bundle plugin makes me uncomfortable. The docs for the plugin say by doing this you're (potentially) changing what gets packed in the jar files as well.

I've been trying to model OSGi support off of what the netty project does, which seems both minimal and non-intrusive.

ctron · 2016-10-13T13:26:42Z

Well I have made good experience with the bundle plugin ... no issues up until now. But I'll understand .. I will try to switch back and still keep it simple.

I did find another issue though .. there is a reference to "com.sun.managment". That may cause troubles since this package could be missing. And I am not sure what will happen with Java 9 regarding that.

kevinherron · 2016-10-13T13:32:48Z

com.sun.management.UnixOperatingSystemMXBean is used in VendorNamespace to get the open and max FD count on *nix systems... if the Java 9 module system takes this ability away it won't be a big deal, it's not essential functionality.

ctron · 2016-10-13T13:47:20Z

Could I wrap this into some sort of "test if possible, don't fail otherwise" section?

ctron · 2016-10-13T13:47:33Z

Then I could make the import optional ... and nothing would fail.

kevinherron · 2016-10-13T13:49:22Z

You could. I don't see any way to make sure it doesn't appear in the imports other than using reflection to check if the class is available and also to invoke the getOpenFileDescriptorCount and getMaxFileDescriptorCount methods.

This change does use the maven-bundle-plugin in order to create OSGi metadata. It falls back to the default configuration, only overriding this when really necessary. Signed-off-by: Jens Reimann <jreimann@redhat.com>

ctron · 2016-10-13T13:51:48Z

No, I wouldn't use reflection for that. Since it doesn't appear in the class definition it should be fine just catching ClassNotFoundException

ctron · 2016-10-13T13:52:05Z

I updated the PR ... better that way? 😉

ctron · 2016-10-13T13:53:34Z

Damn ... I need to do some more testing with Karaf for that.

kevinherron · 2016-10-13T14:03:25Z

I meant for Java 9 compatibility - even trying to import a com.sun package should result in a compilation error if we're not allowed access to that module, no?

ctron · 2016-10-13T14:05:03Z

Hm .. that is a good point... I have no clue how Java 9 would behave when I comes to compiling that.

I guess you just gave me a reason to finally install Java 9 😁

ctron · 2016-10-13T14:05:40Z

I just pushed a new update. That let's Karaf validate the OSGi metadata successfully. But I will try an actually install the bundle. So give me a bit more time.

ctron · 2016-10-13T14:51:52Z

Ok .. it is getting close. But now I run into a "uses" issue:

  Bundle was not resolved because of a uses contraint violation.
  org.osgi.service.resolver.ResolutionException: Uses constraint violation. Unable to resolve resource org.eclipse.milo.stack-client [osgi.identity; osgi.identity="org.eclipse.milo.stack-client"; type="osgi.bundle"; version:Version="0.1.0.SNAPSHOT"] because it is exposed to package 'javax.annotation' from resources org.jsr-305 [osgi.identity; osgi.identity="org.jsr-305"; type="osgi.bundle"; version:Version="3.0.1"] and org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.2.v20150203-1939"; singleton:="true"] via two dependency chains.

Chain 1:
  org.eclipse.milo.stack-client [osgi.identity; osgi.identity="org.eclipse.milo.stack-client"; type="osgi.bundle"; version:Version="0.1.0.SNAPSHOT"]
    import: (&(osgi.wiring.package=javax.annotation)(&(version>=3.0.0)(!(version>=4.0.0))))
     |
    export: osgi.wiring.package: javax.annotation
  org.jsr-305 [osgi.identity; osgi.identity="org.jsr-305"; type="osgi.bundle"; version:Version="3.0.1"]

Chain 2:
  org.eclipse.milo.stack-client [osgi.identity; osgi.identity="org.eclipse.milo.stack-client"; type="osgi.bundle"; version:Version="0.1.0.SNAPSHOT"]
    import: (&(osgi.wiring.package=org.eclipse.milo.opcua.stack.core.serialization.binary)(&(version>=0.1.0)(!(version>=1.0.0))))
     |
    export: osgi.wiring.package=org.eclipse.milo.opcua.stack.core.serialization.binary; uses:=org.eclipse.milo.opcua.stack.core
  org.eclipse.milo.stack-core [osgi.identity; osgi.identity="org.eclipse.milo.stack-core"; type="osgi.bundle"; version:Version="0.1.0.SNAPSHOT"]
    import: (osgi.wiring.package=org.eclipse.milo.opcua.stack.core)
     |
    export: osgi.wiring.package=org.eclipse.milo.opcua.stack.core; uses:=com.google.common.collect
  org.eclipse.milo.stack-core [osgi.identity; osgi.identity="org.eclipse.milo.stack-core"; type="osgi.bundle"; version:Version="0.1.0.SNAPSHOT"]
    import: (&(osgi.wiring.package=com.google.common.collect)(&(version>=19.0.0)(!(version>=20.0.0))))
     |
    export: osgi.wiring.package=com.google.common.collect; uses:=javax.annotation
  com.google.guava [osgi.identity; osgi.identity="com.google.guava"; type="osgi.bundle"; version:Version="19.0.0"]
    import: (osgi.wiring.package=javax.annotation)
     |
    export: osgi.wiring.package: javax.annotation
  org.eclipse.osgi [osgi.identity; osgi.identity="org.eclipse.osgi"; type="osgi.bundle"; version:Version="3.10.2.v20150203-1939"; singleton:="true"]
    at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:393)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
    at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:412)[org.eclipse.osgi-3.10.2.v20150203-1939.jar:]
    at org.apache.karaf.features.internal.service.FeaturesServiceImpl.startBundle(FeaturesServiceImpl.java:1262)[9:org.apache.karaf.features.core:4.0.5]
    at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:840)[9:org.apache.karaf.features.core:4.0.5]
    ... 6 more

ctron · 2016-10-13T15:09:53Z

This one seems to be the issue:

karaf@root()> package:exports -p javax.anno
Package Name                | Version | ID  | Bundle Name
--------------------------------------------------------------
javax.annotation.concurrent | 3.0.1   | 145 | org.jsr-305
javax.annotation.meta       | 3.0.1   | 145 | org.jsr-305
javax.annotation.processing | 1.0.0   | 0   | org.eclipse.osgi
javax.annotation            | 1.0.0   | 0   | org.eclipse.osgi
javax.annotation            | 3.0.1   | 145 | org.jsr-305

This change does prevent the maven-bundle-plugin from importing 'javax.annotation' in order to prevent a "uses violation". Signed-off-by: Jens Reimann <jreimann@redhat.com>

kevinherron · 2016-10-13T15:47:22Z

Yeah, you're on your own with the weird OSGi errors ;) I really have no experience with OSGi, and while I find it to be interesting and somewhat compelling in theory, the reality/implementation seems overly complicated and messy.

ctron · 2016-10-13T15:49:44Z

I know .. and I am just talking to myself in order to remember 😉

This was tricky. And although I seem to have a solution, I don't like the situation.

The JSR 305 annotation live in the same package javax.annotation as the JRE brings along. This is due to the history of JSR 305, which intended to extend Java of course. However this causes a massive problem for OSGi.

As is seems right now JSR 305 will never make into Java. At least not as it is now. But I do see the value of "findbugs". Maybe there is a different way.

ctron · 2016-10-13T16:01:27Z

I am doing one final test now on an actual target. Docker already is fine.

ctron · 2016-10-13T16:33:29Z

Ok ... looks good! Ready to merge, if you like.

kevinherron · 2016-10-13T16:47:26Z

Thanks!

Clean up OSGi metadata

9756392

This change does remove "sun.misc" and "sun.nio.ch" from the list of imported packages. Signed-off-by: Jens Reimann <jreimann@redhat.com>

ctron mentioned this pull request Oct 11, 2016

OSGi duplicate package export: sdk-core vs. sdk-server #59

Closed

Adding a travis ci file

9a76958

Signed-off-by: Jens Reimann <jreimann@redhat.com>

kevinherron reviewed Oct 13, 2016

View reviewed changes

Clean up OSGi metadata generation

4e393e5

This change does use the maven-bundle-plugin in order to create OSGi metadata. It falls back to the default configuration, only overriding this when really necessary. Signed-off-by: Jens Reimann <jreimann@redhat.com>

ctron force-pushed the feature/cleanup_osgi_1 branch from 50dbb8a to 4e393e5 Compare October 13, 2016 13:50

Fix import order

9a1e01f

Don't import 'javax.annotation'

ec8ce27

This change does prevent the maven-bundle-plugin from importing 'javax.annotation' in order to prevent a "uses violation". Signed-off-by: Jens Reimann <jreimann@redhat.com>

kevinherron merged commit 02c0342 into eclipse:master Oct 13, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clean up OSGi metadata #60

Clean up OSGi metadata #60

ctron commented Oct 11, 2016

kevinherron commented Oct 11, 2016

ctron commented Oct 12, 2016

kevinherron left a comment

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016 •

edited

Loading

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

Clean up OSGi metadata #60

Clean up OSGi metadata #60

Conversation

ctron commented Oct 11, 2016

kevinherron commented Oct 11, 2016

ctron commented Oct 12, 2016

kevinherron left a comment

Choose a reason for hiding this comment

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016 • edited Loading

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

ctron commented Oct 13, 2016

kevinherron commented Oct 13, 2016

kevinherron commented Oct 13, 2016 •

edited

Loading