Differences of tycho-surefire-plugin goals plugin-test and test

[kwin]

Recently there was a rename on goals in tycho-surefire-plugin: 43a7a3a.

Now there are two goals:

1. https://github.com/eclipse-tycho/tycho/blob/master/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TychoIntegrationTestMojo.java (named plugin-test) and
2. https://github.com/eclipse-tycho/tycho/blob/master/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TestPluginMojo.java (named test)

Both seems to consider the same class name patterns so it is really unclear to me why there is still the need for two different goals here.
Can someone shed some light on this?

[laeubi]

test fails the build, plugin-test only write the results and requires an additional verify steps see:

https://tycho.eclipseprojects.io/doc/3.0.0/tycho-surefire-plugin/plugin-info.html

test can currently only be used with eclipse-plugin-test packaging the build, plugin-test can only be used with eclipse-plugin packaging.

Also see

• Add a section that explains different ways of testing tycho-plugins #1502

[kwin]

Thanks for the explanation. The javadoc seems outdated then, as

tycho/tycho-surefire/tycho-surefire-plugin/src/main/java/org/eclipse/tycho/surefire/TychoIntegrationTestMojo.java

Line 58 in ac83caa

* are <code>PluginTest*.class, *IT.class</code>) in that runtime. The "test runtime" consists of

still states that the default include patterns are *.IT. Would be nice to enrich the javadoc with the information you have just given here (i.e. that plugin-test can only be used on eclipse-plugin packages.

[laeubi]

Patches are welcome :-)

[mickaelistria]

I believe renaming the goals is similarly to renaming the plugins, a breaking change. I imagine that various clients might have customized one goal and would now be broken. Couldn't we keep older goal names as alias to ensure compatibility? Or should we call next release Tycho 4.0?

[laeubi]

1. why has the goal been renamed?

To make it more clear that it actually do what PDE "Run As Junit Plugin Test" does..

2. why was the default include pattern adjusted?

Because it is the default pattern for surefire/failsafe as well and to not having invent a new default that is nowhere else used. THe different patterns where only introduced because of the default binding required it, but the default binding itself seems to be a bad choice. This was corrected and thus this workaround is not required anymore and make the usage much more flexible.

3. why was the goal parameter renamed without deprecating but still considering the older property?

What goal parameter?

I do understand that no longer binding the goal by default is reasonable to be more in line with maven-failsafe-plugin but I don't see a usecase for combining both maven-failsafe-plugin and tycho-surefire-plugin in package "eclipse-plugin" so why is the previous default pattern no longer suitable for tycho-surefire-plugin:integration-tests/plugin-tests?

See above, you can now choose to use either surefire, failsafe or tycho (are even all or none of them if you like to do so) with eclipse-plugin packaging.

[HannesWell]

The change looks reasonable for me, however I understand that replacing a relatively widely used mojo in a minor version release can bother users.
Is there a reason that speaks against keeping the old mojo with the old preferences as 'deprecated-wrapper' that delegates to the new one and emits a warning to encourage users to migrate? Besides that it has to be done? It can then be deleted ones with Tycho 4.0.

[laeubi]

The change looks reasonable for me, however I understand that replacing a relatively widely used mojo in a minor version release can bother users.

That mojo is not "widely used" ... I would even doubt that anyone is really using that mojo directly already as it was bound to the default execution there is usually no need to use it as it is enabled by default.

Is there a reason that speaks against keeping the old mojo with the old preferences as 'deprecated-wrapper' that delegates to the new one and emits a warning to encourage users to migrate? Besides that it has to be done? It can then be deleted ones with Tycho 4.0.

As said we can start Tycho 4.x right now if it is good for anything from my POV as it dosent matter at all how you call the version but some people might need to update their poms if the not stay at 3.0.0 version ...

Also deprecation in the past has not lead to any good user-experience and people are juts ignoring warnings and on the other hand we have to take the burden of managing legacy code. This has drastically hold back Tychon in the past and was a mess to get rid of all that stuff in 3.x because that much stuff has accumulated. And there are still people using older 2.5 or whatever versions, so all this versioning discussion is a bit useless

So if anyone feels "better" I can update the version to 4.x right now, but this will most likely result in not having a next release until 2023-03 or even 2022-06 ...

[mickaelistria]

Looking at https://github.com/search?p=6&q=tycho+integration-test+filename%3Apom.xml&type=Code , I see that at least Cevelop has built some logic on top of those mojo names, that are definitely to be considered as API.
From here, there are only 2 solutions: migrate to Tycho 4.0 right now, or revert the change in mojo names (that would be my favorite as the mojo names are "only" cosmetic and not worth breaking users).

[laeubi]

From here, there are only 2 solutions: migrate to Tycho 4.0 right now, or revert the change in mojo names (that would be my favorite as the mojo names are "only" cosmetic and not worth breaking users).

I'll update the version to 4.x then right now as there are not only cosmetic changes to happen and this is to much limiting the advance of Tycho development.