OSGi UPS and package export

Question

What is the best way to balance the declared export of packages from a package with the requirements of unit testing?

Consider the "mybundle" package for which you want to write unit tests. The bundle source is stored in the project IDE concept. For instance:

mybundle src/java mybundle.package1 ...java bnd.bnd 

By unit tests, I mean tests of individual POJOs that are not related to the wider OSGi context in which these classes can be used in a bundle. Where possible, tests should be run with the vanilla classes loaded, for example, the JUnit slider in Eclipse.

During development, here are some ways to package unit tests:

Unit tests at beam source

Here unit tests are added to the source folder in the project:

 mybundle src/java mybundle.package1 ...java test/java mybundle.package1.test ...java bnd.bnd 

Pay attention to the added ".test" to delimit packages and avoid package problems.

Typically, there will be a measure to ensure that test classes do not fall into the embedded JAR package.

Unit tests in a separate kit

A separate bundle is added here, the name marked as ".test", as is generally accepted.

 mybundle src/java mybundle.package1 ...java mybundle.test test/java mybundle.package1.test ...java bnd.bnd 

The problem is that since the classes are separated, and running unit tests may not be familiar with the OSGi environment (for example, using the Eclipse JUnit runner), you will need to decorate the run-time class path for the JUnit runner.

Unit tests in fragment

(Thanks @HollyCummins). This creates a separate fragment of the package:

 mybundle.fragment test/java mybundle.package1.test ...java bnd.bnd 

The snippet declares "mybundle" as its host, which allows it to share classes in "mybundle" without the need to export packages.

The disadvantage of this is that since fragment loading is an OSGi concept, you need to run the OSGi container or decorate the classpath.

Export Issues

A problem arises when considering how packages execute Export-Package. It is considered good practice to export as few packages as possible . Nevertheless, unit testing seems to force the export of additional packages.

This is most obvious for the second option, which has a separate test suite. Tests in the test suite must import - pack the tested classes, and the test package must also Export-Package of all tested classes.

Thus, the obvious solution is to rely on unit tests in the source of connectivity, but problems soon arise in non-trivial situations. You may want to share test code, for example, you may have OSGi integration tests in a separate kit. To share the code, you will have to export the test package package, and then, of course, you will also receive the test code in the built-in package!

What is the best way to organize OSGi packages / projects for testing?

Answer 1

The third option is to use OSGi fragments for your unit tests. This ensures that your tests share the class loader with the test code, so there is no need for additional export of packages of internal packages. If necessary, the test fragment can even export the internal packages of the main package. The snippet will have its own package import, so it can pull out a common test code without polluting the import package of the main package.

As mentioned in the comments above and the updated source question, using fragments still leaves you with some questions about how you handle your assembly and class path. If you run your tests outside of the OSGi container, the benefits of fragmented class loaders go a long way, except possibly for pulling imported test dependencies into your IDE.

If you use tests in an OSGi container, the fragments have some disadvantages compared to regular packages, which can be a problem, depending on how you manage your tests. Fragments cannot declare an activator because they do not have an independent life cycle. Declarative services also cannot be registered from a fragment naturally, although Blueprint services usually can .

Answer 2

Using Maven , you can make option 1 very easy to implement. The advantage is that Maven manages your path classes for you, so any code or dependencies that are only required for testing will not end up in the final bundle. You can even put your unit tests in the same package as the classes you are testing so that you have access to classes private to the class from your tests. Since tests are performed using normal class loading, Export-Packages does not affect it at all.