Provide a Junit5 Extension to start an OSGi-Connect-Framework as part of the test without any need for special setup

[laeubi]

Current state

OSGi-Test provides a very convenient and powerful way to (unit) test OSGi code, but the current setup is rather complex and hard to understand for anyone not familiar with OSGi+BND tooling, e.g. the maven example requires the following stuff:

1. A non trivial test.bndrun file https://github.com/osgi/osgi-test/blob/bf9b049afb4bf3331cfa5a222d7566f7bc3ae29f/org.osgi.test.common/test.bndrun#L1-L62
2. bnd-resolver-maven-plugin with non-trivial configuration https://github.com/osgi/osgi-test/blob/bf9b049afb4bf3331cfa5a222d7566f7bc3ae29f/examples/osgi-test-example-mvn/pom.xml#L134-L185
3. bnd-testing-maven-plugin with non trivial configuration https://github.com/osgi/osgi-test/blob/bf9b049afb4bf3331cfa5a222d7566f7bc3ae29f/examples/osgi-test-example-mvn/pom.xml#L162-L185
4. A disabling of the maven-surefire-plugin https://github.com/osgi/osgi-test/blob/bf9b049afb4bf3331cfa5a222d7566f7bc3ae29f/examples/osgi-test-example-mvn/org.osgi.test.example.player.test/pom.xml#L91-L96
5. bnd-maven-plugin with non trivial configuration for the test-plugin itself https://github.com/osgi/osgi-test/blob/bf9b049afb4bf3331cfa5a222d7566f7bc3ae29f/examples/osgi-test-example-mvn/org.osgi.test.example.player.test/pom.xml#L100-L113

Problem with current aproach

While all of this is flexible and powerful in a larger OSGi application setup, it is simply an integration barrier for many other smaller use-cases

1. I have a library project and I don't know much about OSGi but still people ask me to add OSGi support (e.g. Support for the Data Service Specification xerial/sqlite-jdbc#738) for a very limited part of OSGi. Suggesting such a complex setup that requires to restructure large parts of the project will most likely be rejected.
2. I don't want to use an extra project for test but simply use Surefire plugin as-is, and I don't need OSGi for every test so I only selectively want to enable osgi-test it for some test but leave the others alone
3. I don't need/want any special resolving as I can manage a small set of test-pugins and I don't like to afford the extra time required for resolving

Proposed Solution

I have created a proof-of-concept implementation on top of the OSGi Framework connect that drastically reduces the complexity but still enables usage of osgi-test in a unit test environment the following way:

1. Just use a standard maven setup (but running as a plain Unit Test in the IDE e.g. from Eclipse with Run As > JUnit Test will also work) with maven-surefire test in the same module.
2. Add a dependency to org.osgi.test.junit5 and an OSGi framework implementation (equinox in this case) that supports framework-connect:

<dependency>
	<groupId>org.osgi</groupId>
	<artifactId>org.osgi.test.junit5</artifactId>
	<version>${osgi-test.version}</version>
	<scope>test</scope>
</dependency>
<dependency>
	<groupId>org.eclipse.platform</groupId>
	<artifactId>org.eclipse.osgi</artifactId>
	<version>${equinoxVersion}</version>
</dependency> 

3. Create a plain JUnit test like this (based on what would be required for Support for the Data Service Specification xerial/sqlite-jdbc#738 as an example)

@ExtendWith(ServiceExtension.class)
public class OSGiTest {

	@RegisterExtension
	static FrameworkExtension framework = FrameworkExtension.builder()
		.withBundle("org.xerial.sqlite-jdbc", true)
		.withBundle("org.osgi.service.jdbc")
		.build(); 

	@InjectService(filter = "(osgi.jdbc.driver.class=org.sqlite.JDBC)")
	ServiceAware<DataSourceFactory> datasourceFactory;

	@BeforeEach
	public void checkService() {
		assertEquals(1, datasourceFactory.size(), "There should be exactly one DataSourceFactory for SQLite!");
	}
 
	@Test
	public void testCreateDriver() throws SQLException {
		DataSourceFactory service = datasourceFactory.getService();
		assertNotNull(service);
		Driver driver = service.createDriver(null);
		assertNotNull(driver);
		assertTrue(driver instanceof JDBC);
	}
}

I can create a PR with a first implementation based on my proof-of-concept (needs some cleanup and better handling of bundle lookups), but first like to know if this seems valuable for the osgi-test project and could be accepted.

[rotty3000]

I like this idea. And we can extend it in the future so that it can still use a bndrun file to setup the framework. I know here you are banking on the connect model, but I wouldn't preclude using a real framework.

I don't need/want any special resolving as I can manage a small set of test-pugins and I don't like to afford the extra time required for resolving

I don't really agree with that statement since resolving is probably the most important test you need to perform on an OSGi bundle but it's not a blocker for the idea of testing from surefire which I've been meaning to work on for ages, so thanks for taking the lead here 👍

[laeubi]

Thanks @rotty3000 for the feedback andthe support, just want to make clear this obviously should not replace any resolving using BND, that will still be possible and maybe a bnd(run)-file would be an input also for a connect setup.

Also I don't want to say that a resolver is not important, but found for a (unit) test-setup it is often enough (especially if the project has a very limited OSGi scope) to simply have a small set of bundles (like 2 or 3) to have a rather closed-scoped test-context and much more manageable (you get what you declare, not more not less) and faster (than calculating this on each run) but still complete enough.

I'll prepare a PR for an initial implementation, and as you said we can easily build / enhance on top of it later on!

[laeubi]

Jena is another usecase that recently dropped OSGi support as it become too cumbersome to maintain tests in a non-OSGi environment:

• https://issues.apache.org/jira/browse/JENA-2165
• https://lists.apache.org/thread/20h0djofj3h3dwtm728mcclv2zply9jt
• https://issues.apache.org/jira/browse/JENA-2343