Question

I have a question about Tycho packaging types and project structure. I currently have a project that has both source and test source directories following typical Maven convention, which is built using package type 'eclipse-plugin'. This results in tests not being run in the maven build. The most common solution I can find is to separate the test source to a project/bundle of its own and build that via 'eclipse-test-plugin'. My question: What are the drawbacks of keeping the Maven convention and just building the whole project as eclipse-test-plugin instead?

According to http://wiki.eclipse.org/Tycho/Packaging_Types: "Tycho introduces new eclipse-test-plugin packaging type to represent such projects. Build behavior is like regular Eclipse plugins, but these are treated specially at test-time."

This makes me believe that there are actually no drawbacks apart from the resulting bundle possibly depending on bundles that are only required for the test source. However, this is also the case for building via 'eclipse-plugin' (without splitting). Is it safe to say that changing packaging type to 'eclipse-test-plugin' in this case only results in tests being run in the maven build with no other side-effects?

Was it helpful?

Solution

(...) there are actually no drawbacks apart from the resulting bundle possibly depending on bundles that are only required for the test source.

This is the main reason why there are separate eclipse-test-plugin modules for tests in Tycho.

There are no scopes in the OSGi manifest, so the test dependencies would pollute the dependencies of your productive bundle. When you then install your bundle into Eclipse or an RCP, it may pull in test bundles that your productive code doesn't actually need. For most users, this is enough reason to split their code into a productive and a test bundle.

Another potential reason for separating the tests is when you want to explicitly test via the OSGi API of your productive bundle. In this case, you would not use a fragment for the test, which ensures that your tests can only load classes from your productive bundle according to the OSGi package visibility rules.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top