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