[Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

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 <args>' 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Clemens Quoss <cl...@quoss.de>]

Thx for the clarification.

Regards 

Clemens

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

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@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 <cl...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> --
>>> Sent from my phone
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Clemens Quoss <cl...@quoss.de>]

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 <mi...@apache.org>:
>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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> --
>>> Sent from my phone
>>>
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
>> 
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>For additional commands, e-mail: dev-help@maven.apache.org
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Le sam. 31 juil. 2021 à 16:48, Michael Osipov <mi...@apache.org> a
écrit :

> Am 2021-07-31 um 16:40 schrieb Romain Manni-Bucau:
> > Open question: if mvnDebug stays (i am all for it), why deprecating it?
> It
> > is very useful for all dev using embed plugins (most of them) like jetty,
> > tomee, tomcat, meecrowave, renders, etc
>
> What is the problem you see? It add unnecessary maintenance complexity
> which can be replaced with "mvn --debug"
>


Complexity is 1-1 (script can be refactored to source the other one and
makes it "free").

Having 2 scripts enables to tune them more accurately (mem, ports,
exts/settings, ...) and easily for dev and have a better tooling
integration than one for that reason.

Indeed it can be fully inaccurate if we get the alias/custom command
support we spoke about on the list months ago since it is all about tuning
the jvm so maybe another way to make everyone happy (a default debug
"alias" would make it fine/working I guess).




> M
>
> > Le sam. 31 juil. 2021 à 16:32, Robert Scholte <rf...@apache.org> a
> > écrit :
> >
> >> CI can have multiple Maven versions.
> >> Mistakes will happen: users might add --debug assuming verbose logging.
> >> With an Environment Variable the CI server can globally suppress the
> >> option to debug.
> >> I'm also fine with a NO_DEBUG option, but I'd like to have a global way
> to
> >> suppress the impact.
> >>
> >> Robert
> >>
> >>
> >> On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
> >> Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> >>> 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?
> >>
> >> Let me summarize:
> >> If --debug is passed everything will work as before: wait forever
> >> If --debug --batch-mode is passed the VM will wait for at most 30 s.
> >> This value can be modified by a new environment variable.
> >>
> >> Question: Why would a CI system set this to 0 if it is not going to
> >> debug the process?
> >>
> >> M
> >>
> >>> Robert
> >>> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
> >>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>> --
> >>>>> Sent from my phone
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Am 2021-07-31 um 16:40 schrieb Romain Manni-Bucau:
> Open question: if mvnDebug stays (i am all for it), why deprecating it? It
> is very useful for all dev using embed plugins (most of them) like jetty,
> tomee, tomcat, meecrowave, renders, etc

What is the problem you see? It add unnecessary maintenance complexity 
which can be replaced with "mvn --debug"

M

> Le sam. 31 juil. 2021 à 16:32, Robert Scholte <rf...@apache.org> a
> écrit :
> 
>> CI can have multiple Maven versions.
>> Mistakes will happen: users might add --debug assuming verbose logging.
>> With an Environment Variable the CI server can globally suppress the
>> option to debug.
>> I'm also fine with a NO_DEBUG option, but I'd like to have a global way to
>> suppress the impact.
>>
>> Robert
>>
>>
>> On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
>> Am 2021-07-31 um 11:22 schrieb Robert Scholte:
>>> 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?
>>
>> Let me summarize:
>> If --debug is passed everything will work as before: wait forever
>> If --debug --batch-mode is passed the VM will wait for at most 30 s.
>> This value can be modified by a new environment variable.
>>
>> Question: Why would a CI system set this to 0 if it is not going to
>> debug the process?
>>
>> M
>>
>>> Robert
>>> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>> --
>>>>> Sent from my phone
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Open question: if mvnDebug stays (i am all for it), why deprecating it? It
is very useful for all dev using embed plugins (most of them) like jetty,
tomee, tomcat, meecrowave, renders, etc

Le sam. 31 juil. 2021 à 16:32, Robert Scholte <rf...@apache.org> a
écrit :

> CI can have multiple Maven versions.
> Mistakes will happen: users might add --debug assuming verbose logging.
> With an Environment Variable the CI server can globally suppress the
> option to debug.
> I'm also fine with a NO_DEBUG option, but I'd like to have a global way to
> suppress the impact.
>
> Robert
>
>
> On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
> Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> > 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?
>
> Let me summarize:
> If --debug is passed everything will work as before: wait forever
> If --debug --batch-mode is passed the VM will wait for at most 30 s.
> This value can be modified by a new environment variable.
>
> Question: Why would a CI system set this to 0 if it is not going to
> debug the process?
>
> M
>
> > Robert
> > On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>> --
> >>> Sent from my phone
> >>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Am 2021-08-01 um 13:03 schrieb Michael Osipov:
> Am 2021-08-01 um 11:04 schrieb Romain Manni-Bucau:
>> Le dim. 1 août 2021 à 01:22, Stephen Connolly <
>> stephen.alan.connolly@gmail.com> a écrit :
>>
>>> I’m fine with a breaking change.
>>>
>>> I also think batch mode debugging is a special case, we could go with
>>>
>>> —batch-debug
>>>
>>
>> Both options are transversal IMHO so let it be.
>> If you run in debug without custom jvm options (ie --debug or 
>> mvnDebug) it
>> means for maven "hang", no need to make it complicated/contextual.
>> If you want something finer do as today, use MAVEN_OPTS.
> 
> Sigh, I need to agree with Romain here. mvnDebug did not care about -B 
> being passed because it comes before any main class. I think you can try 
> hard to accomondate all cases, but you still will fail with edge cases 
> anyway.
> 
> Make it unconditional from "mvnDebug" to "mvn --debug" since it is only 
> a small step.
> 
> I think we can make it in two steps: In alpha-1 we still accept --debug, 
> but issue a warning that it is deprecated in favor of --verbose and will 
> be repurposed in an upcoming alpha. For those who will deploy the first 
> alpha to a CI server must have an extra look at builds because they 
> might break anyway. I also expect any CI system to highlight warnings.


Moreover, we can add add a general timeout of some minutes (e.g., 3 
min). If should be enough for a developer to attach to a VM or just fail 
the build in CI to get developer's attention to replace --debug with -X 
or --verbose in the future.

M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Am 2021-08-01 um 11:04 schrieb Romain Manni-Bucau:
> Le dim. 1 août 2021 à 01:22, Stephen Connolly <
> stephen.alan.connolly@gmail.com> a écrit :
> 
>> I’m fine with a breaking change.
>>
>> I also think batch mode debugging is a special case, we could go with
>>
>> —batch-debug
>>
> 
> Both options are transversal IMHO so let it be.
> If you run in debug without custom jvm options (ie --debug or mvnDebug) it
> means for maven "hang", no need to make it complicated/contextual.
> If you want something finer do as today, use MAVEN_OPTS.

Sigh, I need to agree with Romain here. mvnDebug did not care about -B 
being passed because it comes before any main class. I think you can try 
hard to accomondate all cases, but you still will fail with edge cases 
anyway.

Make it unconditional from "mvnDebug" to "mvn --debug" since it is only 
a small step.

I think we can make it in two steps: In alpha-1 we still accept --debug, 
but issue a warning that it is deprecated in favor of --verbose and will 
be repurposed in an upcoming alpha. For those who will deploy the first 
alpha to a CI server must have an extra look at builds because they 
might break anyway. I also expect any CI system to highlight warnings.

M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Le dim. 1 août 2021 à 01:22, Stephen Connolly <
stephen.alan.connolly@gmail.com> a écrit :

> I’m fine with a breaking change.
>
> I also think batch mode debugging is a special case, we could go with
>
> —batch-debug
>

Both options are transversal IMHO so let it be.
If you run in debug without custom jvm options (ie --debug or mvnDebug) it
means for maven "hang", no need to make it complicated/contextual.
If you want something finer do as today, use MAVEN_OPTS.



> If you really want to debug batch mode and that way —debug can be
> incompatible with —batch and then we don’t worry about it
>
> On Sat 31 Jul 2021 at 16:06, Michael Osipov <mi...@apache.org> wrote:
>
> > Well, I have just tried.
> >
> > Not providing a timeout is just like providing timeout=0. The socket
> > will wait forever.
> > If your provide a timeout and don't connect after a timeout, this will
> > happen:
> > > Listening for transport dt_socket at address: 8000
> > > ERROR: transport error 203: timed out waiting for connection
> > > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or
> fatal
> > error [transport.c:326]
> > >
> > > D:\Entwicklung\Projekte\maven-integration-testing>if ERRORLEVEL 1 goto
> > error
> >
> > So our timeout idea does not work.
> > We need another idea or accept the breaking change if we want to
> > repurpose --debug.
> >
> > M
> >
> >
> > Am 2021-07-31 um 16:32 schrieb Robert Scholte:
> > > CI can have multiple Maven versions.
> > > Mistakes will happen: users might add --debug assuming verbose logging.
> > > With an Environment Variable the CI server can globally suppress the
> > option to debug.
> > > I'm also fine with a NO_DEBUG option, but I'd like to have a global way
> > to suppress the impact.
> > >
> > > Robert
> > >
> > >
> > > On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
> > > Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> > >> 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?
> > >
> > > Let me summarize:
> > > If --debug is passed everything will work as before: wait forever
> > > If --debug --batch-mode is passed the VM will wait for at most 30 s.
> > > This value can be modified by a new environment variable.
> > >
> > > Question: Why would a CI system set this to 0 if it is not going to
> > > debug the process?
> > >
> > > M
> > >
> > >> Robert
> > >> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
> > >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>>>
> > >>>>> --
> > >>>> Sent from my phone
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: dev-help@maven.apache.org
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > >> For additional commands, e-mail: dev-help@maven.apache.org
> > >>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> > --
> Sent from my phone
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Stephen Connolly <st...@gmail.com>]

I’m fine with a breaking change.

I also think batch mode debugging is a special case, we could go with

—batch-debug

If you really want to debug batch mode and that way —debug can be
incompatible with —batch and then we don’t worry about it

On Sat 31 Jul 2021 at 16:06, Michael Osipov <mi...@apache.org> wrote:

> Well, I have just tried.
>
> Not providing a timeout is just like providing timeout=0. The socket
> will wait forever.
> If your provide a timeout and don't connect after a timeout, this will
> happen:
> > Listening for transport dt_socket at address: 8000
> > ERROR: transport error 203: timed out waiting for connection
> > JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal
> error [transport.c:326]
> >
> > D:\Entwicklung\Projekte\maven-integration-testing>if ERRORLEVEL 1 goto
> error
>
> So our timeout idea does not work.
> We need another idea or accept the breaking change if we want to
> repurpose --debug.
>
> M
>
>
> Am 2021-07-31 um 16:32 schrieb Robert Scholte:
> > CI can have multiple Maven versions.
> > Mistakes will happen: users might add --debug assuming verbose logging.
> > With an Environment Variable the CI server can globally suppress the
> option to debug.
> > I'm also fine with a NO_DEBUG option, but I'd like to have a global way
> to suppress the impact.
> >
> > Robert
> >
> >
> > On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
> > Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> >> 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?
> >
> > Let me summarize:
> > If --debug is passed everything will work as before: wait forever
> > If --debug --batch-mode is passed the VM will wait for at most 30 s.
> > This value can be modified by a new environment variable.
> >
> > Question: Why would a CI system set this to 0 if it is not going to
> > debug the process?
> >
> > M
> >
> >> Robert
> >> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>> --
> >>>> Sent from my phone
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Well, I have just tried.

Not providing a timeout is just like providing timeout=0. The socket 
will wait forever.
If your provide a timeout and don't connect after a timeout, this will 
happen:
> Listening for transport dt_socket at address: 8000
> ERROR: transport error 203: timed out waiting for connection
> JDWP exit error JVMTI_ERROR_NONE(0): could not connect, timeout or fatal error [transport.c:326]
> 
> D:\Entwicklung\Projekte\maven-integration-testing>if ERRORLEVEL 1 goto error

So our timeout idea does not work.
We need another idea or accept the breaking change if we want to 
repurpose --debug.

M


Am 2021-07-31 um 16:32 schrieb Robert Scholte:
> CI can have multiple Maven versions.
> Mistakes will happen: users might add --debug assuming verbose logging.
> With an Environment Variable the CI server can globally suppress the option to debug.
> I'm also fine with a NO_DEBUG option, but I'd like to have a global way to suppress the impact.
> 
> Robert
> 
> 
> On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
> Am 2021-07-31 um 11:22 schrieb Robert Scholte:
>> 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?
> 
> Let me summarize:
> If --debug is passed everything will work as before: wait forever
> If --debug --batch-mode is passed the VM will wait for at most 30 s.
> This value can be modified by a new environment variable.
> 
> Question: Why would a CI system set this to 0 if it is not going to
> debug the process?
> 
> M
> 
>> Robert
>> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>> --
>>>> Sent from my phone
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Le lun. 2 août 2021 à 17:23, Robert Scholte <rf...@apache.org> a écrit :

> Thinks to keep in mind when trying to log for a specific execution of a
> plugin:
> - loggers use the classname as identifier, so you need to know when to the
> execution starts and ends.
> - plugins can call Maven Core code, most likely you want this to be logged
> as part of the plugin execution.
> - multithreading... need I say more?
>
> Most of the time you're only interested in logging of the last failed
> plugin of the previous build, but it is very very tricky to implement.
>

Don't think so, it is very common a plugin execution depends on another
plugin execution so you need both.
This is why I think it is sane to have --log-level [INFO|DEBUG|....]
(whatever the name is) as a starting logging config and not --log-info
<fqn> which will likely miss what is needed.

side note: threading already supports to log the thread the log comes from
so I guess it is sufficient for such a feature, anything more fancy can be
misleading on CI where you can't rely on local debugging when logs are
weird/hard to read.

There are always cases you can't log properly but for end users it is saner
to say "I want to log at level L" rather than "I want the build to be
verbose" or "I want the build to be quiet" which looks like it depends
which plugin rely on a maven toggle. So in case we want a breaking change
in log level CLI options, the log level switch is saner no?

So overall idea is to never try to be more clever than our API enables and
stick to the minimal logging binding configuration we control well and
finally drop the old CLI opts related to the log level in favor of the more
aligned one.
For more advanced use cases, the user can rely on .mvn/jvm.config to fully
tune the slf4j binding we provide (or equivalent xml/yaml/json config file
if the binding accepts it).

Once again (if it is ambiguous), I'm also happy with a status quo (ie no
change compared to maven 3) if it sounds better for everyone.


>
> Robert
> On 2-8-2021 16:06:06, Romain Manni-Bucau <rm...@gmail.com> wrote:
> Le lun. 2 août 2021 à 16:02, Michael Osipov a écrit :
>
> > Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau:
> > > Le dim. 1 août 2021 à 22:37, Michael Osipov a
> > écrit :
> > >
> > >> A prerequisite PR is ready: https://github.com/apache/maven/pull/519
> > >
> > >
> > > Maybe I'm a bit "off" on this one but shouldn't we just enable to
> > configure
> > > slf4j from the command line with "shortcuts"? ie --info --debug
> > > --org.apache.wagon-debug
> > >
> > > Once you know all go through a logger it does not make much sense to
> > have a
> > > verbose toggle anymore IMHO and it is not powerful enough to enable
> what
> > > you need (even the JVM uses system properties to filter the logs you
> > wants
> > > so can be saner to rely on slf4j for us?)
> >
> > It is a bit problematic. SLF4J does not log so you need to delegate to
> > the actual logging implementation. I would prefer --log-level/-L {level}
> > or {logger}:{level}. -L can be provided multiple times.
> > There are open tickets requesting this, but no one has provided a
> > concept how to solve this for all supported logging bindings.
> >
>
> Guess only for the built-in binding is sufficient - if you change the
> binding you can want to ensure it is integrated anyway since other things
> can not work properly like log4j2/logback bindings require some flushing to
> work properly for ex so it is not only a switch.
> That said, the point is to not make --debug specific. An interesting
> question about it do we need quiet then?
>
> Think, if we break anything (+-0 on that), it is where we should go rather
> than renaming anything which means breaking end users for no feature for
> them (which is always a bad idea IMHO).
>
>
> >
> > M
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

Thinks to keep in mind when trying to log for a specific execution of a plugin:
- loggers use the classname as identifier, so you need to know when to the execution starts and ends.
- plugins can call Maven Core code, most likely you want this to be logged as part of the plugin execution.
- multithreading... need I say more?

Most of the time you're only interested in logging of the last failed plugin of the previous build, but it is very very tricky to implement.

Robert
On 2-8-2021 16:06:06, Romain Manni-Bucau <rm...@gmail.com> wrote:
Le lun. 2 août 2021 à 16:02, Michael Osipov a écrit :

> Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau:
> > Le dim. 1 août 2021 à 22:37, Michael Osipov a
> écrit :
> >
> >> A prerequisite PR is ready: https://github.com/apache/maven/pull/519
> >
> >
> > Maybe I'm a bit "off" on this one but shouldn't we just enable to
> configure
> > slf4j from the command line with "shortcuts"? ie --info --debug
> > --org.apache.wagon-debug
> >
> > Once you know all go through a logger it does not make much sense to
> have a
> > verbose toggle anymore IMHO and it is not powerful enough to enable what
> > you need (even the JVM uses system properties to filter the logs you
> wants
> > so can be saner to rely on slf4j for us?)
>
> It is a bit problematic. SLF4J does not log so you need to delegate to
> the actual logging implementation. I would prefer --log-level/-L {level}
> or {logger}:{level}. -L can be provided multiple times.
> There are open tickets requesting this, but no one has provided a
> concept how to solve this for all supported logging bindings.
>

Guess only for the built-in binding is sufficient - if you change the
binding you can want to ensure it is integrated anyway since other things
can not work properly like log4j2/logback bindings require some flushing to
work properly for ex so it is not only a switch.
That said, the point is to not make --debug specific. An interesting
question about it do we need quiet then?

Think, if we break anything (+-0 on that), it is where we should go rather
than renaming anything which means breaking end users for no feature for
them (which is always a bad idea IMHO).


>
> M
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Le lun. 2 août 2021 à 16:02, Michael Osipov <mi...@apache.org> a écrit :

> Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau:
> > Le dim. 1 août 2021 à 22:37, Michael Osipov <mi...@apache.org> a
> écrit :
> >
> >> A prerequisite PR is ready: https://github.com/apache/maven/pull/519
> >
> >
> > Maybe I'm a bit "off" on this one but shouldn't we just enable to
> configure
> > slf4j from the command line with "shortcuts"? ie --info --debug
> > --org.apache.wagon-debug
> >
> > Once you know all go through a logger it does not make much sense to
> have a
> > verbose toggle anymore IMHO and it is not powerful enough to enable what
> > you need (even the JVM uses system properties to filter the logs you
> wants
> > so can be saner to rely on slf4j for us?)
>
> It is a bit problematic. SLF4J does not log so you need to delegate to
> the actual logging implementation. I would prefer --log-level/-L {level}
> or {logger}:{level}. -L can be provided multiple times.
> There are open tickets requesting this, but no one has provided a
> concept how to solve this for all supported logging bindings.
>

Guess only for the built-in binding is sufficient - if you change the
binding you can want to ensure it is integrated anyway since other things
can not work properly like log4j2/logback bindings require some flushing to
work properly for ex so it is not only a switch.
That said, the point is to not make --debug specific. An interesting
question about it do we need quiet then?

Think, if we break anything (+-0 on that), it is where we should go rather
than renaming anything which means breaking end users for no feature for
them (which is always a bad idea IMHO).


>
> M
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Am 2021-08-02 um 09:39 schrieb Romain Manni-Bucau:
> Le dim. 1 août 2021 à 22:37, Michael Osipov <mi...@apache.org> a écrit :
> 
>> A prerequisite PR is ready: https://github.com/apache/maven/pull/519
> 
> 
> Maybe I'm a bit "off" on this one but shouldn't we just enable to configure
> slf4j from the command line with "shortcuts"? ie --info --debug
> --org.apache.wagon-debug
> 
> Once you know all go through a logger it does not make much sense to have a
> verbose toggle anymore IMHO and it is not powerful enough to enable what
> you need (even the JVM uses system properties to filter the logs you wants
> so can be saner to rely on slf4j for us?)

It is a bit problematic. SLF4J does not log so you need to delegate to 
the actual logging implementation. I would prefer --log-level/-L {level} 
or {logger}:{level}. -L can be provided multiple times.
There are open tickets requesting this, but no one has provided a 
concept how to solve this for all supported logging bindings.

M


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Romain Manni-Bucau <rm...@gmail.com>]

Le dim. 1 août 2021 à 22:37, Michael Osipov <mi...@apache.org> a écrit :

> A prerequisite PR is ready: https://github.com/apache/maven/pull/519


Maybe I'm a bit "off" on this one but shouldn't we just enable to configure
slf4j from the command line with "shortcuts"? ie --info --debug
--org.apache.wagon-debug

Once you know all go through a logger it does not make much sense to have a
verbose toggle anymore IMHO and it is not powerful enough to enable what
you need (even the JVM uses system properties to filter the logs you wants
so can be saner to rely on slf4j for us?)




>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

A prerequisite PR is ready: https://github.com/apache/maven/pull/519

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

CI can have multiple Maven versions. 
Mistakes will happen: users might add --debug assuming verbose logging.
With an Environment Variable the CI server can globally suppress the option to debug.
I'm also fine with a NO_DEBUG option, but I'd like to have a global way to suppress the impact.

Robert


On 31-7-2021 16:08:36, Michael Osipov <mi...@apache.org> wrote:
Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> 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?

Let me summarize:
If --debug is passed everything will work as before: wait forever
If --debug --batch-mode is passed the VM will wait for at most 30 s.
This value can be modified by a new environment variable.

Question: Why would a CI system set this to 0 if it is not going to
debug the process?

M

> Robert
> On 30-7-2021 21:46:46, Michael Osipov 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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> --
>>> Sent from my phone
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

Am 2021-07-31 um 11:22 schrieb Robert Scholte:
> 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?

Let me summarize:
If --debug is passed everything will work as before: wait forever
If --debug --batch-mode is passed the VM will wait for at most 30 s. 
This value can be modified by a new environment variable.

Question: Why would a CI system set this to 0 if it is not going to 
debug the process?

M

> Robert
> On 30-7-2021 21:46:46, Michael Osipov <mi...@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>> --
>>> Sent from my phone
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

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 <mi...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --
>> Sent from my phone
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>> --
>> Sent from my phone
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

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 <mi...@apache.org> 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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>> --
> Sent from my phone
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Stephen Connolly <st...@gmail.com>]

So now I cannot debug Maven issues that happen when running in batch mode?
We should document that specific case uses MAVEN_OPTS

On Tue 27 Jul 2021 at 16:01, Michael Osipov <mi...@apache.org> 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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
> --
Sent from my phone

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

I have now updated the PR with batch mode in mind. Please have a look.

Note: the PR is of course in complete because it needs modification in 
the Java side.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Michael Osipov <mi...@apache.org>]

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 <mi...@apache.org> 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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [Maven 4] Collapsing mvnDebug into mvn

[Robert Scholte <rf...@apache.org>]

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.
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.

Robert

On 26-7-2021 21:00:26, Michael Osipov <mi...@apache.org> 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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org