RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Re: catchall on the way: yay! Re: plexus version: I was about to ask if the next version of the compiler plugin will include this, but I see it's already there. Nice! -Original Message- From: Alexander Kriegisch Sent: Saturday, December 23, 2023 11:48 PM To: users@maven.apache.org Subject: Re: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - alexan...@kriegisch.name Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Thanks for the feedback. Happy it works for you now. Catch-all category: I am on it (probably after Xmas). I will also add a few more categories to be recognised correctly and salvage their headers in multiple languages, too. Or maybe, the catch-all will replace all the special stuff, if I can make it generic enough. -- Alexander Kriegisch https://clicktime.symantec.com/15siFBb9d4NJgGHWiNXKG?h=1vmIObVnLTcyoQ9TsPnuTXCFU7Mf1SG7sMP5BNOvmzk=&u=https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 10:21 (GMT +07:00): > Okay, I tried again with more realistic settings and indeed it now works! > (That is, I gave it 700 megs of heap instead of one meg) > Thank you! This actually truly works! > > (I still feel that there should be a "catchall" category of compiler output so > that anything that maven can't make sense of doesn't silently swallowed.) > > But it works! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com. __ If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html. __ For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. __ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Thanks for the feedback. Happy it works for you now. Catch-all category: I am on it (probably after Xmas). I will also add a few more categories to be recognised correctly and salvage their headers in multiple languages, too. Or maybe, the catch-all will replace all the special stuff, if I can make it generic enough. -- Alexander Kriegisch https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 10:21 (GMT +07:00): > Okay, I tried again with more realistic settings and indeed it now works! > (That is, I gave it 700 megs of heap instead of one meg) > Thank you! This actually truly works! > > (I still feel that there should be a "catchall" category of compiler output so > that anything that maven can't make sense of doesn't silently swallowed.) > > But it works! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Okay, I tried again with more realistic settings and indeed it now works! (That is, I gave it 700 megs of heap instead of one meg) Thank you! This actually truly works! (I still feel that there should be a "catchall" category of compiler output so that anything that maven can't make sense of doesn't silently swallowed.) But it works! -Original Message- From: Alexander Kriegisch Sent: Saturday, December 23, 2023 7:53 PM To: users@maven.apache.org Subject: Re: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - alexan...@kriegisch.name Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Just found this in my spam folder. Your invalid e-mail address and the strange link replacements in some of your messages maybe. This kind of obfuscation might derail the server-side filters. Anyway, I already said mvn dependency:tree a minute sago in my other message. mvn help:effective-pom -Doutput=effective-pom.xml is helpful, too. -- Alexander Kriegisch https://clicktime.symantec.com/15t6KP9J8Qx4aAou1S5kN?h=gjD-CfhzFG_NEND692vyjsGzpBpicHoC55k2ALzIIoc=&u=https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 01:53 (GMT +07:00): > Actually no, wait. I changed the pom as you described but I think the > build is still using the old plexus version. > Is there a way to be sure? > > -Original Message- > From: mark.yagnatin...@barclays.com.INVALID > > Sent: Saturday, December 23, 2023 1:51 PM > To: users@maven.apache.org > Subject: RE: Why does Plexus Compiler parse compiler output, when forked? > (was: > maven debugging frustrations) > > > CAUTION: This email originated from outside our organisation - > mark.yagnatin...@barclays.com.INVALID Do not click on links, open > attachments, or respond unless you recognize the sender and can > validate the content is safe. > Also: just tested with your new and improved version. > To speed up the build failures I gave it even less heap (just one meg). > It doesn't seem to help; all I get is "compilation failure" > And thanks for putting up with my attitude; I'll try to do better. > > -Original Message- > From: Yagnatinsky, Mark : Markets Pre Trade > Sent: Saturday, December 23, 2023 12:50 PM > To: Maven Users List > Subject: RE: Why does Plexus Compiler parse compiler output, when forked? > (was: > maven debugging frustrations) > > Okay you win, stack trace below. My bad, sorry, I should know better. > Also, thanks for explaining the parsing picture: that's not how I > expected it to work at all! > I never thought maven expected this much structure from the compiler messages. > > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: GC overhead limit exceeded > at com.sun.tools.javac.util.List.of(List.java:135) > at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) > at > > com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436) > at > > com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226) > at > > com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215) > at > > com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155) > at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628) > at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665) > at > > com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > -Original Message- > From: Alexander Kriegisch > Sent: Saturday, December 23, 2023 3:03 AM > To: users@
Re: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Just found this in my spam folder. Your invalid e-mail address and the strange link replacements in some of your messages maybe. This kind of obfuscation might derail the server-side filters. Anyway, I already said mvn dependency:tree a minute sago in my other message. mvn help:effective-pom -Doutput=effective-pom.xml is helpful, too. -- Alexander Kriegisch https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 01:53 (GMT +07:00): > Actually no, wait. I changed the pom as you described but I think the build > is > still using the old plexus version. > Is there a way to be sure? > > -Original Message- > From: mark.yagnatin...@barclays.com.INVALID > > Sent: Saturday, December 23, 2023 1:51 PM > To: users@maven.apache.org > Subject: RE: Why does Plexus Compiler parse compiler output, when forked? > (was: > maven debugging frustrations) > > > CAUTION: This email originated from outside our organisation - > mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, > or respond unless you recognize the sender and can validate the content is > safe. > Also: just tested with your new and improved version. > To speed up the build failures I gave it even less heap (just one meg). > It doesn't seem to help; all I get is "compilation failure" > And thanks for putting up with my attitude; I'll try to do better. > > -Original Message- > From: Yagnatinsky, Mark : Markets Pre Trade > Sent: Saturday, December 23, 2023 12:50 PM > To: Maven Users List > Subject: RE: Why does Plexus Compiler parse compiler output, when forked? > (was: > maven debugging frustrations) > > Okay you win, stack trace below. My bad, sorry, I should know better. > Also, thanks for explaining the parsing picture: that's not how I expected it > to work at all! > I never thought maven expected this much structure from the compiler > messages. > > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: GC overhead limit exceeded > at com.sun.tools.javac.util.List.of(List.java:135) > at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) > at > > com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436) > at > > com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285) > at > > com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226) > at > > com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215) > at > > com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155) > at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628) > at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665) > at > > com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) > at com.sun.tools.javac.main.Main.compile(Main.java:523) > at com.sun.tools.javac.main.Main.compile(Main.java:381) > at com.sun.tools.javac.main.Main.compile(Main.java:370) > at com.sun.tools.javac.main.Main.compile(Main.java:361) > at com.sun.tools.javac.Main.compile(Main.java:56) > at com.sun.tools.javac.Main.main(Main.java:42) > > -Original Message- > From: Alexander Kriegisch > Sent: Saturday, December 23, 2023 3:03 AM > To: users@maven.apache.org > Subject: Why does Plexus Compiler parse compiler output, when forked? (was: > maven debugging frustrations) > > > CAUTION: This email originated from outside our organisation - > alexan...@kriegisch.name Do not click on links, open attachments, or respond > unless you recognize the sender and can validate the content is safe. >> There's nothing that special about MY stack trace... just run javac on >> a largish module with a tiny heap. > > Well, that is an abstract description, and instead of just sending one or two > stack traces, now you are burdening me with trying to reproduce your problem > without a reproducer. Do you think, that makes sense or is particularly nice? > I > just wanted *any* example stack trace for this error. > >> In the meantime, I have a question. Why is maven in the busines
Re: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Thanks for the stack trace. :-) I quickly tested it in a unit test with Plexus Compiler 2.14.2, and like I guessed already, the stack trace is detected, but not the two header lines above, because Plexus Javac does not search for them (yet). I would expect you to see the stack trace, but you said you did not. Are you really sure that you added the Plexus dependencies to Maven Compiler Plugin, like Ishowed you in my Maven example? Can you maybe check with 'mvn dependency:tree'? -- Alexander Kriegisch https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 24.12.2023 00:50 (GMT +07:00): > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: GC overhead limit exceeded > at com.sun.tools.javac.util.List.of(List.java:135) > at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) > at > > com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Actually no, wait. I changed the pom as you described but I think the build is still using the old plexus version. Is there a way to be sure? -Original Message- From: mark.yagnatin...@barclays.com.INVALID Sent: Saturday, December 23, 2023 1:51 PM To: users@maven.apache.org Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - mark.yagnatin...@barclays.com.INVALID Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. Also: just tested with your new and improved version. To speed up the build failures I gave it even less heap (just one meg). It doesn't seem to help; all I get is "compilation failure" And thanks for putting up with my attitude; I'll try to do better. -Original Message- From: Yagnatinsky, Mark : Markets Pre Trade Sent: Saturday, December 23, 2023 12:50 PM To: Maven Users List Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) Okay you win, stack trace below. My bad, sorry, I should know better. Also, thanks for explaining the parsing picture: that's not how I expected it to work at all! I never thought maven expected this much structure from the compiler messages. The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: GC overhead limit exceeded at com.sun.tools.javac.util.List.of(List.java:135) at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) at com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436) at com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226) at com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) -Original Message- From: Alexander Kriegisch Sent: Saturday, December 23, 2023 3:03 AM To: users@maven.apache.org Subject: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - alexan...@kriegisch.name Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. > There's nothing that special about MY stack trace... just run javac on > a largish module with a tiny heap. Well, that is an abstract description, and instead of just sending one or two stack traces, now you are burdening me with trying to reproduce your problem without a reproducer. Do you think, that makes sense or is particularly nice? I just wanted *any* example stack trace for this error. > In the meantime, I have a question. Why is maven in the business of > trying to "parse" the output of javac? Why can't it give me its output > verbatim, as if javac were a mysterious black box binary blob with > totally unknown behaviour? That is actually a good question. I was wondering about the same thing, too. Let me remind you, I am not a maintainer or even have commit rights on Plexus Compiler. I am a simple user, just like you, and last week contributes a little patch for the very first time. The patch improved something, it was not a rewrite. Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement the same Compiler interface and even extend from the same AbstractCompiler base class. No matter if they compile in process or out of process, they are calle by Maven Compiler via interface method CompilerResult Compiler.performCompile(CompilerConfiguration) throws CompilerException I.e., they have to return a CompilerResult,and that one e.g. has a List getCompilerMessages() method. I.e., Maven Compiler d
RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Also: just tested with your new and improved version. To speed up the build failures I gave it even less heap (just one meg). It doesn't seem to help; all I get is "compilation failure" And thanks for putting up with my attitude; I'll try to do better. -Original Message- From: Yagnatinsky, Mark : Markets Pre Trade Sent: Saturday, December 23, 2023 12:50 PM To: Maven Users List Subject: RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) Okay you win, stack trace below. My bad, sorry, I should know better. Also, thanks for explaining the parsing picture: that's not how I expected it to work at all! I never thought maven expected this much structure from the compiler messages. The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: GC overhead limit exceeded at com.sun.tools.javac.util.List.of(List.java:135) at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) at com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436) at com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226) at com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) -Original Message- From: Alexander Kriegisch Sent: Saturday, December 23, 2023 3:03 AM To: users@maven.apache.org Subject: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - alexan...@kriegisch.name Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. > There's nothing that special about MY stack trace... just run javac on > a largish module with a tiny heap. Well, that is an abstract description, and instead of just sending one or two stack traces, now you are burdening me with trying to reproduce your problem without a reproducer. Do you think, that makes sense or is particularly nice? I just wanted *any* example stack trace for this error. > In the meantime, I have a question. Why is maven in the business of > trying to "parse" the output of javac? Why can't it give me its output > verbatim, as if javac were a mysterious black box binary blob with > totally unknown behaviour? That is actually a good question. I was wondering about the same thing, too. Let me remind you, I am not a maintainer or even have commit rights on Plexus Compiler. I am a simple user, just like you, and last week contributes a little patch for the very first time. The patch improved something, it was not a rewrite. Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement the same Compiler interface and even extend from the same AbstractCompiler base class. No matter if they compile in process or out of process, they are calle by Maven Compiler via interface method CompilerResult Compiler.performCompile(CompilerConfiguration) throws CompilerException I.e., they have to return a CompilerResult,and that one e.g. has a List getCompilerMessages() method. I.e., Maven Compiler does not expect a dump of output and error streams and a single result OK or failed, but a list of error messagesof different kinds, such as errors, warnings, infos etc. When compiling out of process (fork=true) instead of Java tools interface, the compiler output must be parsed, which is a rather crude and imperfect heuristic approach. Actually, it is amazing that it works as good as it does at all. Simply running the forked compiler VM with a non-English locale can make the difference between an error correctly identified or not, because since at least JDK 8, there are 3 locales, since JDK 21 4 locales in OpenJDK
RE: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations)
Okay you win, stack trace below. My bad, sorry, I should know better. Also, thanks for explaining the parsing picture: that's not how I expected it to work at all! I never thought maven expected this much structure from the compiler messages. The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: GC overhead limit exceeded at com.sun.tools.javac.util.List.of(List.java:135) at com.sun.tools.javac.util.ListBuffer.append(ListBuffer.java:129) at com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436) at com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226) at com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:665) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:950) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:857) at com.sun.tools.javac.main.Main.compile(Main.java:523) at com.sun.tools.javac.main.Main.compile(Main.java:381) at com.sun.tools.javac.main.Main.compile(Main.java:370) at com.sun.tools.javac.main.Main.compile(Main.java:361) at com.sun.tools.javac.Main.compile(Main.java:56) at com.sun.tools.javac.Main.main(Main.java:42) -Original Message- From: Alexander Kriegisch Sent: Saturday, December 23, 2023 3:03 AM To: users@maven.apache.org Subject: Why does Plexus Compiler parse compiler output, when forked? (was: maven debugging frustrations) CAUTION: This email originated from outside our organisation - alexan...@kriegisch.name Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe. > There's nothing that special about MY stack trace... just run javac on > a largish module with a tiny heap. Well, that is an abstract description, and instead of just sending one or two stack traces, now you are burdening me with trying to reproduce your problem without a reproducer. Do you think, that makes sense or is particularly nice? I just wanted *any* example stack trace for this error. > In the meantime, I have a question. Why is maven in the business of > trying to "parse" the output of javac? Why can't it give me its output > verbatim, as if javac were a mysterious black box binary blob with > totally unknown behaviour? That is actually a good question. I was wondering about the same thing, too. Let me remind you, I am not a maintainer or even have commit rights on Plexus Compiler. I am a simple user, just like you, and last week contributes a little patch for the very first time. The patch improved something, it was not a rewrite. Basically, all Plexus compilers (Javac, C#, AspectJ, Eclipse Java) implement the same Compiler interface and even extend from the same AbstractCompiler base class. No matter if they compile in process or out of process, they are calle by Maven Compiler via interface method CompilerResult Compiler.performCompile(CompilerConfiguration) throws CompilerException I.e., they have to return a CompilerResult,and that one e.g. has a List getCompilerMessages() method. I.e., Maven Compiler does not expect a dump of output and error streams and a single result OK or failed, but a list of error messagesof different kinds, such as errors, warnings, infos etc. When compiling out of process (fork=true) instead of Java tools interface, the compiler output must be parsed, which is a rather crude and imperfect heuristic approach. Actually, it is amazing that it works as good as it does at all. Simply running the forked compiler VM with a non-English locale can make the difference between an error correctly identified or not, because since at least JDK 8, there are 3 locales, since JDK 21 4 locales in OpenJDK. I do not want to elaborate any further - you get the picture. That in some cases, especially when the build fails for any reason, the error message is not parsed out correctly, is exactly what needs improvement and what was partly addressed by my patch, at least if a stack trace happens to be part of the compiler output. Cheers -- Alexander Kriegisch https://clicktime.symantec.com/15t5ejaoBdG3n3Nk8C4vS?h=lY-QL6rWusTeyzIz0RujRgAvrvPPWo66hf-ZSgB36q4=&u=https://scrum-master.de mark.yagnatin...@barclays.com.INVALID schrieb am 23.12.2023 10:40 (GMT +07:00):
