@slawekjaranowski
Here are two ITs. So two POMs for them.
There's a very little difference between both POMs. The dependencies are same in both. You could reach the same with the original POM. We usually alter the dependencies in the Maven profiles, that's the way how it should be done with both ITs. Then we as developers would have a simple situation because we would analyse only one place of IT sources/POM.

Another radical proposition, drop this it tests at all, testng-engine it is not our product it is extension for junit-platform.

So mention in documentation such possibility even without configuration examples and point to product page should be enough.

Our product is provider for junit-platform so we should take care about it not for every extension for junit-platform.

@slawekjaranowski
This is not a bug fix for users. It would not be a problem to postpone this to a later release.
Then we can continue on our discussions longer...

Ok, It is only improvement and can be postpone to a later release.
But we should know that can generate issues for as, like SUREFIRE-2043

@slawekjaranowski
It would be worth to test the TestNG groups as well.
Because it would be interesting to see how the TestNG groups are bound to JUnit5 groups. There can be more such features on both sides.

@slawekjaranowski
If we are so close to cut a new release, we should push this change and we can continue with the discussion and refactoring or joining the POMs in one later. WDYT?
If you would find time to do the last modification it would be worth.
It would be worth to provide it to the customers with working engine.

@Tibor17
Ok, I removed additional test, and use only existing.

I think that exclusions in most of time it is workaround for problem in target project.

As we see on the project page https://github.com/junit-team/testng-engine there are no exclusions in examples.

And next https://repo1.maven.org/maven2/org/junit/support/testng-engine/1.0.1/testng-engine-1.0.1.pom
has dependency to testng in runtime scope
but for junit-platform-engine they use compile scope.

In the old revision of com.github.testng-team:testng-junit5, the exclusion was because the TestNG team released only one version of the engine with dependency of old junit-platform-engine 1.7.0. So I was interested what happens if we can still use it by override it to 1.8.2. I found that the testng-junit5 still works.
I excluded the dependency and did not override it directly for internal testing purposes and for the reason to avoid a situation that I override Jupiter API to 5.8.2 but junit-platform-engine 1.7.0.

@slawekjaranowski

And next https://repo1.maven.org/maven2/org/junit/support/testng-engine/1.0.1/testng-engine-1.0.1.pom
has dependency to testng in runtime scope
but for junit-platform-engine they use compile scope.

They would appear in our test classpath.
See the table which describes that runtime and compile scoped artifacts would be resolved in test classpath.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope

Now with newer version of testng-engine is better I think.
Simply can be used with the newest junit-jupiter-api:5.8.2 and simple configuration should be shown to user.

So I prefer to not propagate workaround with exclusion to users, whose simply copy and paste it.

Is it exclusion is still needed and reasonable?
If it is needed and we show it, we should describe why we use exclusion?

I hope that JUnit team upgrade testng-engine to newest version of junit-platform.

WDYT?

@slawekjaranowski
I did not say that testng-engine has some problem. I only said that Surefire understands Jupiter Api and resolves it into engine, and we only prevent from strange versions combination- see the comment in the POM in the second commit - it is not about bug, it is about clarity of deps.
I added second commit.

Ok, thanks.
I assume that now is ok.
So when build have finished I will merge it.

Resolve #2851