Tycho surefire mojo can install source bundles causing silent resource duplications since tycho 4.0.6

[jstroleny]

Hello,

I just want to ask about new behavior introduced in tycho 4.0.6 which potentially can cause test failures for existing projects (it happened for our project).

I think it is related to following issue #3635, but I'm not sure if it can be considered as issue in surefire as well.
I'm attaching minimal reproducer (inspired from one existing tycho ITs - surefire.bundleResources), so you can check old and new behavior locally.

Steps to reproduce:

1. run mvn clean verify (it runs tests with tycho 4.0.5 by default)
   • expected: tests are passing
   • actual: tests are passing
2. update to tycho 4.0.6 (in pom.xml and .mvn/extensions.xml)
3. run mvn clean verify again
   • expected: tests are passing
   • actual: tests failed
4. Check config.ini in work directory, it contains:
   • surefire.testDependencies/tests/bundle2.tests/target/bundle2.tests-1.0.0.jar
   • surefire.testDependencies/tests/bundle2.tests/target/bundle2.tests-1.0.0-sources.jar
     Both bundles can contain same resources, thus once installed into osgi runtime, they are duplicated.

Since tycho 4.0.6, the surefire mojo can install also source bundles into test runtime which can cause resource duplications during runtime. It can negatively affect existing tests as resources are duplicated, these resources can be e.g. definitions of internal platform to be started, but once it is duplicated it is started twice.

According to surefire testRuntime description, it says following:

test runtime is minimal (defined by the transitive dependencies of the test bundle plus and the test harness)

but can be source bundles be considered to constitute minimal test runtime even where there is no transitive dependency to source bundles?

Minimal reproducer: surefire.testDependencies.zip

Thanks

[sratz]

I can reproduce this and the behavior has indeed changed with
2053d37#diff-9a9726aa0be8197a6082b700e8219a18531b5f9ba103b2f9fc5f162b154794eaR74
when resolving the target platform.

In the normal use-cases this is intended: target platforms contains every possible IU, then the later stages (publish-products, etc.) decide what to actually consume from that set of available IUs.

However, in this surefire scenario the target platform resolver is also used to create the test environment. In this case the additional source IUs are not required.

The target platform resolver should probably get a switch to control the behavior of
2053d37#diff-9a9726aa0be8197a6082b700e8219a18531b5f9ba103b2f9fc5f162b154794eaR74

I'll look into it when I am back from my vacation in a few weeks.