I'm currently digging the sources and found that sure-fire-plugin
requires "eclipse-test-plugin" packaging, but literally all places in
the code referencing "eclipse-test-plugin" doing so to handle
"eclipse-test-plugin" the same as "eclipse-plugin"... So this feels like
were doing all this stuff just for the sake to tell "can be run with
sure-fire".
Right, tycho-surefire-plugin would be better not requiring eclipse-test-plugin. The eclipse-test-plugin packaging type just makes the call to tycho-surefire-plugin implicit, but it could very well be that instead of eclipse-test-plugin, we move the call to tycho-surefire-plugin into eclipse-plugin packaging type and put a guard in the entrance of tycho-surefire-plugin:test mojo to not run when not relevant. I think the eclipse-test-plugin also configures the compile goal so that classes go to the project.build.testOutputDirectory.
Making tycho-surefire-plugin work with plain eclipse-plugin without requiring an eclipse-test-plugin would be a good change in Tycho,
About "surefire requires the bundle to be build":
if I take a look at [1] there are separate phases for compiling "normal"
classes and test-classes, so maybe a very first step would be that tycho
actually compile marked test-source folders in this phase?
That would be a welcome change; but it means Tycho now reads .classpath which AFAIK it isn't doing so far.
IMO, if we can allow bundle build to be controlled by .classpath instead of build.properties, that would overall be a benefit.
next step seems for me that as tycho-surefire runs in the
integration-test phase the package might be enhanced to actually produce
two artifacts:
- plugin_version.jar
- plugin-test_version.jar
where the second simply contains additional all classes from the
"test-compile" phase
Yes.
as a last step, surefire-plugin must check not for the
"eclipse-test-plugin" but also for existence of an attached
"plugin-test" artifact and the use this to run.
Yes. Alternative could be to just check for existence of content in target/test-classes.
IMO, the packaging of test-classes into a fragment should be a duty of tycho-surefire-plugin.
beside that, it would be good if we could run test that don't require an
OSGi-Framework to run in the "test" phase. Could this be archived with
traditional maven-surefire (e.g. will it "see" the plugin dependencies?)
Tycho does fill the project model with the resolved dependencies, and maven-surefire-plugin uses it. So when invoking maven-surefire-plugin, it does run against the dependencies as a classpath. But beware that some bundles have nested jars, and that, plain Java doesn't like...
As it seems currently there is no support for this usecase and we are
creating something new we should defiantly take into account how to make
this works more nice than currently. For example I could think about
that we add additional properties to the classpath entry (like the
"maven derived" that tells surefire if this is a folder for
- plain unit test
- eclipse plugin test
- eclipse plugin test require ui-harness
If we can get consensus about this I might be possible to add support
for some of the steps described above.
All that requires first that Tycho is able to ignore build.properties and reads .classpath instead.
