Split Packages

Java 8 SE contains a number of packages that are normally part of J2EE, but only contain a subset of the J2EE classes and interfaces. This causes issues when one tries to port J2EE based functionality to OSGI. Some packages that can cause issues:

javax.transaction
javax.transaction.xa
javax.annotation

The best cure is to unsplit the package by adding it to the system classpath. Main drawback is that we can no longer start our container with java -jar felix.jar. Also some bundles may expect a certain package version (e.g 1.1 for java.transaction as specified in the OSGI enterprise specification), so we also need to instruct the system bundle to export the bundle with the correct version. Some possibilities:

java -cp felix.jar;jta-1.1.jar -Dorg.osgi.framework.system.packages.extra=java.transaction;version=1.1 org.apache.felix.main.Main
java -Xbootclasspath/a:jta-1.1.jar -Dorg.osgi.framework.system.packages.extra=java.transaction;version=1.1 -jar felix.jar
Add jta-1.1.jar to lib/ext directory of the jre, and then java -Dorg.osgi.framework.system.packages.extra=java.transaction;version=1.1 -jar felix.jar. Not really recommended as this will cause issues each time you upgrade or change jre version
When using a bnd run file:
-runpath: jta-1.1.jar
-systempackages: javax.transaction;version=1.1

Too bad, java -jar felix.jar was just too easy to be true

Adding the missing classes to the system classpath does not solve all problems, as these packages may still be exported by application bundles. So one needs to carefully inspect all third party bundles for exporting packages already exported by the system bundle.

If you prefer to life dangerously and overrule the Java SE package by exporting the package from a bundle, you need a per package strategy:

javax.transaction

Why in SE: The Java8 SE version only contains a few exceptions that to my knowledge are only used by a few CORBA implementation classes.
What does EE add: The JTA transaction interfaces
Safe to export:If you do not need to catch CORBA exceptions, one can safely export this package from an application bundle, and that is why com.amplifino.transaction.provider exports javax.transaction.

javax.transaction.xa

Why in SE: Provides the XAREsource interface, the link between the javax.sql and javax.transaction packages
What does EE add: Nothing, not really a split package
Safe to export: Any bundle exporting javax.transaction.xa should be shot on sight, as having multiple versions of XAResource will cause strange error in JTA transactions. (XADataSource is loaded by the boot classloader and will use the Java8 XAResource instance, while the Transaction service implementation will use the exported version). One may need to use org.osgi.framework.system.packages.extra to up the version exported by the system bundle to 1.1 as specified by the OSGI JTA Transaction Services specification.

javax.annotation

Why in SE: The Resource and PostConstruct annotation are used by the JAX-WS (SOAP) implementation included in Java 8 to inject a WebServiceContext instance into a web service instance.
What does EE add: ManagedBean and Priority annotation. While we do not care much about ManagedBean, Priority is used by JAX-RS (REST, not part of Java8 SE) to specify the execution order of its various request filters.
Safe to export: Not if you are using the standard JAX-WS implementation with the builtin web server. Web services registered with Endpoint.publish using a WebServiceContext instance will typically fail with an NPE. The soap whiteboard provided by nestor is not affected, as it uses an invoker that shields the web service instance from the JAX-WS implementation.
Note that javax.annotation package is also used for the dormant JSR305 specification request (e.g. @Nullable), further complicating the issue.