Le sam. 31 juil. 2021 à 16:48, Michael Osipov <micha...@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 <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 > >
