olamy commented on PR #479: URL: https://github.com/apache/maven-surefire/pull/479#issuecomment-1153112560
> When I see the [commit](https://github.com/apache/maven-surefire/pull/479/commits/a8295bfebd4c067d4caa1323ae80ecfee42883ac), I have to say that this PR is a pure mess and disaster, the providers must not be touched in the ITs POM. The POM changes have nothing to do with any build speed up, it has nothing to do with `-T3`. It's a pure hack which affects functionality of the tests and it is very risky solution. As I said before in Slack or GH, the way how the build can be faster is to focus on the most slow IT classes and those are only few and those are Parameterized and they can be speed up as it was before (I deleted due to Maven Resolver) only the way that the Maven local repo would have all artifacts pre-loaded or the Resolver would be failsafe which is not now and so the concurrent ITs would fail the Resolver of course. Maiking the project build parallel would speed up the build in 5 min because all modules except the surefire-its are much faster in comparison to the ITs, so there is no reason to think about these "improvements". The penalty would wrong behavior of the tests, and that's worst! > > Another story is embedded Maven. This was not stable solution for us some time ago because it shares system props and env is shared and the developer has no notion about while writing the test, and so there is the risc the IT however succeeds on Jenkins but fails in real environment. That's the reason why it was removed several years ago in the surefire-its/pom.xml. 2 facts: 1. build plan - before this commits in master: ``` ➜ maven-surefire git:(master) mvn clean install -pl :surefire-its -am [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] Apache Maven Surefire [pom] [INFO] Maven Surefire Integration Tests [jar] ``` - after this change: ``` ➜ maven-surefire git:(multithread-build-possible) mvn clean install -pl :surefire-its -am [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Reactor Build Order: [INFO] [INFO] Apache Maven Surefire [pom] [INFO] Surefire Shared Utils [jar] [INFO] SureFire Logger API [jar] [INFO] SureFire API [jar] [INFO] Surefire Extensions API [jar] [INFO] Surefire Extensions SPI [jar] [INFO] SureFire Booter [jar] [INFO] Maven Surefire Test-Grouping Support [jar] [INFO] SureFire Providers [pom] [INFO] Shared JUnit3 Provider Code [jar] [INFO] Shared Java 5 Provider Base [jar] [INFO] Shared JUnit4 Provider Code [jar] [INFO] Shared JUnit48 Provider Code [jar] [INFO] SureFire JUnit Runner [jar] [INFO] SureFire JUnit4 Runner [jar] [INFO] Maven Surefire Common [jar] [INFO] SureFire JUnitCore Runner [jar] [INFO] SureFire JUnit Platform Runner [jar] [INFO] SureFire TestNG Utils [jar] [INFO] SureFire TestNG Runner [jar] [INFO] Surefire Report Parser [jar] [INFO] Maven Surefire Plugin [maven-plugin] [INFO] Maven Failsafe Plugin [maven-plugin] [INFO] Maven Surefire Report Plugin [maven-plugin] [INFO] Maven Surefire Integration Tests [jar] ``` I tend to think the second build plan is more correct regarding to what the `surefire-its` wants to achieve. the goal is not really to use only parallel as it will provide only a bit shorter build time but hey it's still an improvement. 2. use of verifier with auto mode: - without this any branch of the build is about 1h20minutes see https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-surefire/job/master/ - with this change: https://ci-maven.apache.org/blue/organizations/jenkins/Maven%2Fmaven-box%2Fmaven-surefire/detail/PR-479/33/pipeline/24 branch are about 50 minutes (still issues to have a look for jdk11+) (locally the build is down from 1h10m to 42minutes Personally I think it worth it just to help us developing and contributor to not waste too much time. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@maven.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
