Right, it is suspend, I misinterpreted the description of server.

Can we introduce an environment variable for it, so CI servers can set it to 0?

Robert
On 30-7-2021 21:46:46, Michael Osipov <micha...@apache.org> wrote:
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