Add JUnit RunListener to Tycho Surefire Plugin

[vaclavHala]

We have some custom RunListener we'd like to add to each of our tests (i.e. register it in parent pom and have all test bundles inherit it).

So far I managed to get the listener working by registering it like this in the parent pom

<plugin>
    <groupId>org.eclipse.tycho</groupId>
    <artifactId>tycho-surefire-plugin</artifactId>
    <configuration>
        <providerProperties>
            <property>
                <name>listener</name>
                <value>my.custom.Listener</value>
            </property>
        </providerProperties>

and then adding bundle containing this class as explicit dependency to META-INF/MANIFEST.MF of every test bundle.

While this works, I'm not happy about having to add it to each test as every time we add a new test bundle the build breaks (failed to find the listener class).

So what I tried to do was mark the bundle containing the listener as Fragment-Host: org.eclipse.tycho.surefire.osgibooter, as that seems to be the bundle which does the lookup by reflection at runtime, and adding the listener bundle as extra requirement to target-platform-configuration in the parent. Problem with this approach is that target resolution fails with such setup:

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: my.custom.listener 1.0.0
[ERROR]   Missing requirement: my.custom.listener 1.0.0 requires 'osgi.bundle; org.eclipse.tycho.surefire.osgibooter 0.0.0' but it could not be found

which seems wrong to me as the booter obviously is part of the final target, this can be seen by running any tests with the -Dtycho.printBundles flag.

Finally, my question - is the approach with fragment I took reasonable and should I create a feature request for exposing the booter in the target? Is there some better way I didn't think of to achieve what I'm trying to do with what is already available (i.e. add some code visible to tycho-surefire classpath without having to explicitly depend on it from the test bundle)?

I have found thread asking for pretty much the same thing https://www.eclipse.org/lists/tycho-user/msg06256.html but no resolution there.

[laeubi]

which seems wrong to me as the booter obviously is part of the final target

You are mixing thinks here, the booter is not part of the project resolution (e.g. you will never really see it on the compile path) but only part of the test-execution framework, that are different things.

and adding the listener bundle as extra requirement to target-platform-configuration in the parent

I think that https://www.eclipse.org/tycho/sitedocs/tycho-surefire-plugin/integration-test-mojo.html#dependencies is more suitable for this (never checked if a plain jar is then even enough).

[vaclavHala]

Got an update on this.

I tried changing the fragment-host to org.junit but that did not help. I think because the booter bundle depends on junit via package import rather than whole bundle import the code I add by my fragment is still not visible to the ProviderFactory.

However looking at the manifest of the booter it requires org.eclipse.core.runtime by bundle import so attaching my fragment to that and explicitly exporting package with my Listener class (so it gets exposed to booter along with other exports from the core.runtime bundle) does the trick. I updated the example code with this change to show it works.

I feel what I did here is more of a hack than proper solution since it depends on implementation of the booter (its imports in manifest). Using the booter as the fragment host would be more correct solution as it is the intuitive thing to do (in my opinion). So I still think it would be reasonable to have the option to use it as fragment host as I originally described. What do you think?

[laeubi]

All of this relies on internal implementation details and might break in a future Tycho release. "global listeners" is just something that do not work well in OSGi and the standard way would be to register the listener programmatically.

[vaclavHala]

the standard way would be to register the listener programmatically

Could you elaborate on this please? What would that look like?

[laeubi]

JUnit 4: https://www.swtestacademy.com/junit-listeners/
JUnit 5: https://stackoverflow.com/questions/48595037/whats-the-junit-5-way-for-runlisteners

[vaclavHala]

Hm the junit4 approach seems to require me to register it in each test class explicitly which I wanted to avoid.

The junit5 approach with service loader seems promising, Ill look into that some more. Though I fear I will hit osgi visibility problem there as well as the surefire junit5 provider does not seem to be an osgi consumer of service loader services as described here http://docs.osgi.org/specification/osgi.cmpn/7.0.0/service.loader.html . I might be wrong about that so I'll just try and see.

In either case, I guess we can close this. Thanks for your help