eclipse-tycho
Tycho 5.x: Context class loader set in Surefire Plugin leads to ClassNotFoundExceptions
We are currently trying to update to Tycho 5.0. A lot of our test cases fails because of different context class loader (compared to 4.x).
The context class loader set by Tycho in OsgiSurefireBooter allows to load classes reachable by the test plugin.
In some third party libraries (or even the JRE) the context class loader is used to load factory classes, with the Tycho class loader they get access to classes they actually should not have.
In our case REST-Assured checks for access to some optionally available classes using context class loader: https://github.com/rest-assured/rest-assured/blob/master/rest-assured-common/src/main/groovy/io/restassured/internal/common/classpath/ClassPathResolver.java#L21 We are using a version of jakarta.xml.bind which is outside of the version range used in REST-Assured as optional dependency.
In similar ways javax.xml.parsers.DocumentBuilderFactory.newInstance() also returns an implementation provide by Apache Xerces bundles and not the an implementation part of the JRE.
If required I can try to create an example next week.
If your tests depend on ContextClassLoading it might be best to setup an explicit one (whatever that is meant to be) then you have full control over that part in action.
As mentioned we were using Tycho 4.0.13 before and had no issues (also launching in IDE works without issues). With this change https://github.com/eclipse-tycho/tycho/commit/18045c9b9a19d7702c5fcf17eb7f095ca35d85b1 behaviour has changed.
My expectation would be that Tycho Surefire does not behave differently than launching in PDE.
Btw: The work around you have proposed works for us. Still I think would be great if you could explain why context class loader has changed in such a way.
My expectation would be that Tycho Surefire does not behave differently than launching in PDE
Tycho and PDE working completely different (using different code bases) and anything that requires implicit context classlaoding could or could not work as we made no guarantee here. Especially as there is not a single test failing and also we can build all verification builds. So if you think your case should be supported you need to supply at least an integration-test to demonstrate the issue and then it might be enhanced / fixed and we will ensure it will not make any problems in the future.
Still I think would be great if you could explain why context class loader has changed in such a way.
The contex-classlaoder behavior is required due to how surefire/junit works and prior to this it breaks once in a while when new junit versions are released and we need multiple providers here (what simply do not scale well). Basically what is loaded for surefire/junit must be somewhat compatible to what is sued in the test because otherwise we have classlaoding incompatibilities.