Le dim. 1 août 2021 à 01:22, Stephen Connolly <
[email protected]> 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 <[email protected]> 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 <[email protected]> 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: [email protected]
> > >>>>>>> For additional commands, e-mail: [email protected]
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: [email protected]
> > >>>>>> For additional commands, e-mail: [email protected]
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: [email protected]
> > >>>>> For additional commands, e-mail: [email protected]
> > >>>>>
> > >>>>> --
> > >>>> Sent from my phone
> > >>>>
> > >>>
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: [email protected]
> > >>> For additional commands, e-mail: [email protected]
> > >>>
> > >>>
> > >>
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [email protected]
> > >> For additional commands, e-mail: [email protected]
> > >>
> > >>
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> > --
> Sent from my phone
>

Reply via email to