Thx for the clarification.

Regards 

Clemens

Am 31. Juli 2021 10:58:07 MESZ schrieb Robert Scholte <rfscho...@apache.org>:
>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 <clem...@quoss.de> 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: dev-unsubscr...@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>
>>>>> --
>>>> Sent from my phone
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>For additional commands, e-mail: dev-h...@maven.apache.org
>>

Reply via email to