The discussion is about using --debug -B (combination of these 2 flags). With Maven 3 this meant batch-mode + debug level logging. The proposal for Maven 4 is to change debug level logging to --verbose/-X and redefine --debug for debugging instead of mvnDebug. So if you're only using -B there's no issue. And if you are using --debug -B you can switch to -X -B which will behave the same for Maven 3 and 4.
Robert On 30-7-2021 22:59:09, Clemens Quoss <[email protected]> wrote: Hello! I may not understand much of this discussion going on here. But we use the -B option for having the default behaviour of maven-release in literally thousands of our Jenkins build jobs. Even only having to wait on a debug timeout would not be acceptable and would force us to remove this in a customized version of maven- release. Regards Clemens Am 30. Juli 2021 21:46:37 MESZ schrieb Michael Osipov : >I guess you mean suspend and not server. >Your idea may work, but still is problematic. If the breakpoint is quite >early you will miss in your IDE and then you need to start over. >I think -B and --debug are special cases and I believe that a timeout is >acceptible since the build is halted, but more importantly will continue >*automatically* after it. Just like waiting for a network resource which >might be slow. > >M > >Am 2021-07-30 um 18:31 schrieb Robert Scholte: >> I wonder if this is a realistic issue. In the cases I know with the >> batch-mode the interactive part is skipped and code falls back to defaults. >> If there are issues, they're more much likely to happen in the interactive >> mode. >> Maybe a more reasonable solution is to use server="n" (default) for batch >> mode, server="y" for interactive mode: no delay in batchmode and still the >> option to attach a remote debugger. >> >> thanks, >> Robert >> >> >> On 30-7-2021 16:56:15, Michael Osipov wrote: >> Am 2021-07-30 um 14:31 schrieb Stephen Connolly: >>> So now I cannot debug Maven issues that happen when running in batch mode? >>> We should document that specific case uses MAVEN_OPTS >> >> Not now, nothing has been committed/merged yet. This is just a PoC. >> Robert and me thought about this. We could add an environment var which >> circumvents the batch mode if you really want to debug in batch mode. An >> alternative would be if you running in batch mode runjdwp would receive >> a timeout value in milliseconds to wait for a debugger to attach. Say 30 >> 000 ms and then the process will continue. In interactive mode, the JVM >> will wait forever. >> See here: >> https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/conninv.html#Invocation >> >> WDYT? >> >>> On Tue 27 Jul 2021 at 16:01, Michael Osipov wrote: >>> >>>> So you say that -B will implicitly disable --debug without any further >>>> notice? >>>> >>>> I logically agree that batch contradicts debug which requires >>>> interaction with the suspended VM. Both does not make sense. >>>> >>>> Note: Colors are easier now. They now work just like people are used >>>> with grep --color... >>>> >>>> Am 2021-07-27 um 16:27 schrieb Robert Scholte: >>>>> batch mode means no interaction, but the debug-flag is an interaction >>>> (java process is waiting for input). >>>>> So it doesn't make sense to have both activated. >>>>> This will prevent CI jobs to hang when using --debug (if they assume >>>> this means logging at debug level) >>>>> batch implies disabling colours, but if you *only* want to disable >>>> colors, you should use -Dstyle.color=never >>>>> >>>>> Robert >>>>> On 27-7-2021 13:56:45, Michael Osipov wrote: >>>>> OK, let me sum up what you are proposing: >>>>> >>>>> Am 2021-07-27 um 12:39 schrieb Robert Scholte: >>>>>> I actually like the idea of renaming --debug/-X to --verbose/-X and >>>> we're actually lucky. >>>>>> When renaming we can add a message that --debug for logging at debug >>>> level has been renamed to --verbose. >>>>> >>>>> A preceding commit will rename --debug to verbose. This PR will reuse >>>>> --debug instead of -dj/--debug-java. I assume that most do -X and not >>>>> --debug, but that's a wild guess. >>>>> >>>>>> Due to the nature of debugging (waiting until remote debugger is >>>> attached) the message will be visible so users can easily kill the running >>>> process and restart Maven with the new command. >>>>>> In case of batch-mode as done by CI servers I think we can ignore the >>>> --debug-flag, so if they were using the --debug flag, they'll just get less >>>> logging. >>>>> >>>>> Here you expect that -B and --debug (new) are mutually exclusive? I >>>>> don't know how likely it is, but maybe someone whats to debug w/o >>>>> colors, send to file or omit the progress. >>>>> Is that what you have in mind? >>>>> >>>>> M >>>>> >>>>>> On 26-7-2021 21:00:26, Michael Osipov wrote: >>>>>> Hi folks, >>>>>> >>>>>> I was recently working on MNG-7075 and while the solution is straight >>>>>> forward [1], it just feels awkward. For a long time I had the idea that >>>>>> the mvnDebug script can be completely collapsed into mvn with a single >>>>>> switch. >>>>>> Therefore, I have created a draft PR [2] which works in the Windows >>>>>> command prompt and the Bourne shell. It completely obsoletes MNG-7075, >>>>>> mvnDebug and a nice bonus: When mvnDebug is run, output still refers to >>>>>> 'mvn', e.g., 'mvn -r ' this is inconsistent until now, but will be >>>>>> consistent in the future. mvnDebug would remain as-is, but would emit a >>>>>> warning that it is deprecated. >>>>>> mvnDebug is used ony by Maven developers like us and of course >>>>>> extension/plugin devs. The majory are just users which don't care. >>>>>> >>>>>> Note: I am not happy with -dj, but wasn't able to come up with something >>>>>> better for the moment. I would prefer --debug to be renamed to --verbose >>>>>> and --debug to be recycled as Java debug mode, but that is likely >>>>>> impossible, I guess. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Michael >>>>>> >>>>>> [1] https://github.com/apache/maven/pull/515 >>>>>> [2] https://github.com/apache/maven/pull/517 >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> -- >>> Sent from my phone >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] >
