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 <micha...@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 <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 > > -- Sent from my phone
