Re: [Maven 4] Collapsing mvnDebug into mvn
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 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 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: >
Re: Feature proposal: Dependency deprecation indicators
Hi all, I would like to suggest to write a small specification of the feature you brought up. I have somethink in mind similar to the JEP process for Java. I could create a repo at Github, so that we can work there on the feature description and ask other people to review it or to contribute to it. WDYT? Oliver Am 28.07.21 um 12:10 schrieb Chris Kilding: Hello, I would like to propose a new Maven feature: dependency deprecation indicators. In a nutshell, the idea is to let maintainers set a 'deprecated' metadata indicator on a Maven artifact in a repository. This will indicate to users that the artifact should no longer be used. The Maven CLI tools could then react to deprecation indicators in the appropriate ways: - `mvn` itself: Print a warning when deprecated dependencies are seen. - Maven Enforcer Plugin: Add a rule which throws an error when deprecated dependencies are seen. - Maven Dependency Tree: Print a [deprecated] notice next to any deprecated dependency in the tree. - ...and so on We can also envisage automated agents like Dependabot using these indicators to alert developers about deprecated dependencies in their stacks, and assisting developers to remove them. Some of the major build tools outside the JVM already have deprecation indicators: - NPM: https://docs.npmjs.com/cli/v7/commands/npm-deprecate - Nuget: https://docs.microsoft.com/en-us/nuget/nuget-org/deprecate-packages - Composer / Packagist: https://tomasvotruba.com/blog/2017/07/03/how-to-deprecate-php-package-without-leaving-anyone-behind/ So the feature has precedent, and I believe it would be useful to have in Maven. If there is demand for it, I am willing to work on it. There are definitely several good questions to be answered about what exactly the feature would look like, so questions and comments are welcome :) Regards, Chris Kilding - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- N Oliver B. Fischer A Schönhauser Allee 64, 10437 Berlin, Deutschland/Germany P +49 30 44793251 M +49 178 7903538 E o.b.fisc...@swe-blog.net S oliver.b.fischer J oliver.b.fisc...@jabber.org X http://xing.to/obf - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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
Re: [Maven 4] Collapsing mvnDebug into mvn
Le sam. 31 juil. 2021 à 16:48, Michael Osipov 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 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 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 >
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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 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
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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 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
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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
Re: [Maven 4] Collapsing mvnDebug into mvn
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
Re: [Maven 4] Collapsing mvnDebug into mvn
Thx for the clarification. Regards Clemens Am 31. Juli 2021 10:58:07 MESZ schrieb Robert Scholte : >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 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,
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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
Re: [Maven 4] Collapsing mvnDebug into mvn
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 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
