Hi Tibor, there is no way you violate the community process like that. Olivier did address most of the issues, he did pass the review process and while discussion was still ongoing there is no consensus on a revert nor discusion so think we should revert the revert, finish the discussion if needed and move forward.
Side note: it is ok to be alone against the community in idea, it is wrong to be in acts. Just my 2cts but this can't be right @asf. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le dim. 15 févr. 2026 à 04:02, Olivier Lamy <[email protected]> a écrit : > Hi, > > I was surprised to see these changes reverted, as they were addressing > issues affecting a significant number of Windows users. > The PRs in question resolved problems for users running on Windows > without WMIC but using Java 9+. They also aimed to improve the current > behaviour and incorporate points that had previously been raised > during review. > The compatibility concern mentioned appears to affect a relatively > narrow subset of users: Java 8 users who rely on WMIC without > PowerShell installed. > While it is important to consider such edge cases, there may be ways > to mitigate the impact without fully reverting improvements that > benefit a broader group of users. > For users in that situation, possible options include: > - remaining on Surefire 3.5.4 (they are already using old Java 8 and > old Windows version) > - upgrading to at least Java 9 > - installing PowerShell > > I am also concerned about the process/community aspect. These PRs had > received few community approvals, which indicated consensus to move > forward. > Reverting them without prior discussion on the mailing list or in the > PR bypasses that consensus-building process. > I would therefore suggest reverting those reverts as they are > affecting changes that have already been approved. > Regards > Olivier > > On Sun, 15 Feb 2026 at 10:07, Tibor Digaňa <[email protected]> wrote: > > > > Hi all, > > > > We started this discussion 8 days ago, it is still pending. > > > > Sylwester L. asked me to open the discussion here 8 days ago, so I did. > We > > still have not made any consensus, and Olivier proactively pushed his > work > > into master, I reverted his change because we still have not finished the > > analysis and a proposal. Due to there are two issues and not one, both > must > > be fixed altogether and everybody has to understand what we are doing, > why > > and how. > > > > @Olivier Lamy, I require from you to inform me about everything what you > > are doing in this project and you will invite me in every PR you > > participate on and this way we will discuss together and we we > collaborate > > together. > > > > So there is nothing such a single person to validate changes. > We are a developer community here. PRs are public and can be validated > by any community member. > > > There are several technical notices on my side: > > > > 1. We have also customers with old Windows systems: Windows XP, Windows > > Server. > > 2. It is not true that the PowerShell is the only solution because not > > everybody wants to install it nor installed it yet. > > 3. It is true that using OS-naturally native commands we are > significantly > > mitigating the risk (the risk that some native binary is not recognized). > > 4. It is true that the *ProcessHandle* [1] is *totally avoiding this > issue*. > > Unlikely the PS or WMIC or PowerShell commands which are only at the > > mitigation level - there is always some risk but it is minimum. > > 5. It is true that using a kind of Java reflection (or a modern > > *MethodHandle* [2]) we can call *ProcessHandle* [1] without any problem > > even on Java 8 build process of this project (customer's build process is > > different story - there *ProcessHandle* can be activated). > > 6. If we do not want to switch to Java 9, I am fine with that, but then > we > > have to continue in the risk mitigation and we should not push the > customer > > to something he does not like and it is reinstallation of old systems > with > > PowerShell (which might not be installable). In this case adding > PowerShell > > is okay but we have to keep WMIC for old Windows systems, and PS for *Nix > > systems. Due to the Java 9 API is simple, and it is simple to call (in > > principal) *ProcessHandle.of(PPID).isAlive()* via the reflection - we > have > > these experiences, we can switch from *risk mitigation* to a *guarantee*. > > Since of Maven 4, we can delete all of these PowerShell, WMIC, PS > commands > > and call *ProcessHandle.of(PPID).isAlive() *without reflection - trivial. > > 7. Additionally, we didn't say that there is one more problem. The > customer > > would not recognize this issue if the native commands fallback-ed to the > > PING mechanism. There is a bug, and it does not matter if you add > > PowerShell or the trick with Java 9. It does not matter! This is missing, > > still in the code and that's the reason why yesterday I made the analysis > > of these commands. > > > > [1]: > > > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ProcessHandle.html > > [2]: > > > https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/MethodHandle.html > > > > > > Solution proposal: > > > > After this analysis, it's clear that the Java8-based projects have to use > > the native commands. WMIC has to fallback to PowerShell if IOException is > > thrown (Chain of Responsibility design pattern). PS command would stay on > > *Nix platforms. The Java 9 process checker takes the precedense on Java > 9+, > > this must be implemented as Strategy pattern and the appropriate object > > would be selected by platform conditions. Regarding the point (7) the > > *ProcessChecker* must be fixed and the handler of the execute method as > > well in order to fallback to PING. No IT deleted. Only two unit tests > added > > for PowerShell - Windows and *ProcessHandle* - Java9. > > > > I am very sorry for the inconvenience. > > > > This would require the reactions, and personal talks. > > > > I would open Apero beer meeting on every last Tuestady via Google Meet > > where we can friendly talk about the Maven in general. We somehow stopped > > this activity last year and it's the time to continue with this very nice > > activity again. I will send the appointment tomorrow. > > > > > > Cheers > > > > Tibor17 > > > > > > > > On Sat, Feb 7, 2026 at 1:21 AM Tibor Digaňa <[email protected]> > wrote: > > > > > Hi all, > > > > > > I would like to have your opinion regarding this issue reported on > GitHub: > > > "Surefire and Failsafe stop working on latest versions of Windows due > to > > > missing wmic" > > > Please see the link here > > > https://github.com/apache/maven-surefire/issues/3176 > > > > > > I am the author who developed the PPID Process Checker. When I worked > on > > > it together with Michael Osipov, we reached a consensus. It was a very > nice > > > personal collaboration, and now I would be glad to have this guy back > in > > > the active Maven Team again :-) > > > That time we used Java 7 or Java 8, or even both, however Java 9 was > > > available in the world. We could not use the Java 9 however it could > really > > > help us. Therefore we decided to call the system library "wmic" on > Windows, > > > and "ps" on *Nix world, and not Java 9. > > > > > > Due to the Microsoft Windows removed "wmic", I am open to move complete > > > Surefire project under Java 9. > > > > > > I remember how problematic life it was when we had to support both > Java 7 > > > and Java 8 at the same time. I do not want to support two Java versions > > > again. > > > It would be easier for us to get a confidence from the Maven community > and > > > switch to Java 9 directly. > > > I hope we would get an exception in the list of Maven plugins. > > > > > > BTW, One more remark. There are strengths to destroy this project. > Let's > > > ignore these strengths. We can prevent from this happening if we are > > > positive and we are friendly working together. > > > > > > > > > Cheers > > > Tibor17 > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
