Re: PLXCOMP-1 and improving compiler-message parsing
Thanks Olivier! It should be rocking now, hopefully. /Anders On Thu, Nov 8, 2012 at 3:34 PM, Olivier Lamy ol...@apache.org wrote: done 2012/11/8 Anders Hammar and...@hammar.net: I've sent a pull requests which, IMHO, cleans things up in the javac part. Mainly I've focused on having the success param of CompilerResult to signal if the compilation is successful or not, regardless of if there are any error messages or not. The old code always added a fake error message (which we had to do with the old CompilerError object). This will also require changes to the current maven-compiler-plugin logic, as it expects there to be an error message. It doesn't pay attention to the success param of CompilerResult. I have this fixed locally and I'll commit as soon as there is a new snapshot of plexus-compiler deployed. /Anders On Mon, Oct 29, 2012 at 11:09 PM, Anders Hammar and...@hammar.net wrote: I've added comments to the pull request itself. /Anders On Sun, Oct 28, 2012 at 10:42 PM, Olivier Lamy ol...@apache.org wrote: Hi, So have a look at those changes https://github.com/sonatype/plexus-compiler/pull/10. This break backward comp but as it will be easier in the future to improve the compiler result without breaking backward comp. 2012/10/19 Olivier Lamy ol...@apache.org: I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not
Re: PLXCOMP-1 and improving compiler-message parsing
I've sent a pull requests which, IMHO, cleans things up in the javac part. Mainly I've focused on having the success param of CompilerResult to signal if the compilation is successful or not, regardless of if there are any error messages or not. The old code always added a fake error message (which we had to do with the old CompilerError object). This will also require changes to the current maven-compiler-plugin logic, as it expects there to be an error message. It doesn't pay attention to the success param of CompilerResult. I have this fixed locally and I'll commit as soon as there is a new snapshot of plexus-compiler deployed. /Anders On Mon, Oct 29, 2012 at 11:09 PM, Anders Hammar and...@hammar.net wrote: I've added comments to the pull request itself. /Anders On Sun, Oct 28, 2012 at 10:42 PM, Olivier Lamy ol...@apache.org wrote: Hi, So have a look at those changes https://github.com/sonatype/plexus-compiler/pull/10. This break backward comp but as it will be easier in the future to improve the compiler result without breaking backward comp. 2012/10/19 Olivier Lamy ol...@apache.org: I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be
Re: PLXCOMP-1 and improving compiler-message parsing
done 2012/11/8 Anders Hammar and...@hammar.net: I've sent a pull requests which, IMHO, cleans things up in the javac part. Mainly I've focused on having the success param of CompilerResult to signal if the compilation is successful or not, regardless of if there are any error messages or not. The old code always added a fake error message (which we had to do with the old CompilerError object). This will also require changes to the current maven-compiler-plugin logic, as it expects there to be an error message. It doesn't pay attention to the success param of CompilerResult. I have this fixed locally and I'll commit as soon as there is a new snapshot of plexus-compiler deployed. /Anders On Mon, Oct 29, 2012 at 11:09 PM, Anders Hammar and...@hammar.net wrote: I've added comments to the pull request itself. /Anders On Sun, Oct 28, 2012 at 10:42 PM, Olivier Lamy ol...@apache.org wrote: Hi, So have a look at those changes https://github.com/sonatype/plexus-compiler/pull/10. This break backward comp but as it will be easier in the future to improve the compiler result without breaking backward comp. 2012/10/19 Olivier Lamy ol...@apache.org: I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools
Re: PLXCOMP-1 and improving compiler-message parsing
I've added comments to the pull request itself. /Anders On Sun, Oct 28, 2012 at 10:42 PM, Olivier Lamy ol...@apache.org wrote: Hi, So have a look at those changes https://github.com/sonatype/plexus-compiler/pull/10. This break backward comp but as it will be easier in the future to improve the compiler result without breaking backward comp. 2012/10/19 Olivier Lamy ol...@apache.org: I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since
Re: PLXCOMP-1 and improving compiler-message parsing
Hi, So have a look at those changes https://github.com/sonatype/plexus-compiler/pull/10. This break backward comp but as it will be easier in the future to improve the compiler result without breaking backward comp. 2012/10/19 Olivier Lamy ol...@apache.org: I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and
Re: PLXCOMP-1 and improving compiler-message parsing
So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey --**--** - To unsubscribe, e-mail:
Re: PLXCOMP-1 and improving compiler-message parsing
+1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6 https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1 http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin.
Re: PLXCOMP-1 and improving compiler-message parsing
Just a question regarding plexus-compiler: Is it known to be used by anything but the m-compiler-p? As we're bumping to v2.0, how about breaking backwards compatibility? I'm thinking that we should change the signature of Compiler.compile so that it doesn't just return a list of messages, but rather return the result of the compilation (together with a list of messages). (Also, I wouldn't mind changing the name of the CompilerError class to e.g. CompilerMessage.) /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6 https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1 http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because
Re: PLXCOMP-1 and improving compiler-message parsing
On Fri, Oct 19, 2012 at 7:16 AM, Anders Hammar and...@hammar.net wrote: Just a question regarding plexus-compiler: Is it known to be used by anything but the m-compiler-p? As we're bumping to v2.0, how about breaking backwards compatibility? I'm thinking that we should change the signature of Compiler.compile so that it doesn't just return a list of messages, but rather return the result of the compilation (together with a list of messages). (Also, I wouldn't mind changing the name of the CompilerError class to e.g. CompilerMessage.) This component is so obscure that the following is perhaps not relevant, but ... Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6 https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1 http://jira.codehaus.org/browse/PLXCOMP-1
Re: PLXCOMP-1 and improving compiler-message parsing
Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List
Re: PLXCOMP-1 and improving compiler-message parsing
I think this change makes sense. But I know at least one external dependency: http://groovy.codehaus.org/Groovy-Eclipse+compiler+plugin+for+Maven I don't know if Andrew is listening here ? 2012/10/19 Anders Hammar and...@hammar.net: Changing the version number to 2.0 is not good enough to make incompatible changes, due to the working of dependency resolution. Sure it is, out of a configuration management perspective. Out of a Maven dep resolution perspective it might not be optimal. Preserving backwards compatibility is always desirable but sometimes it might just not be possible or might come at a high cost. Not saying it's the case here, but just generally speaking. Maven will, of course, cheerfully and silently substitute 2.0 for 1.2 in a dependency tree, with unhappy result. You have to, of course, change the G or the A, and the package names, to allow interoperation. Wee, that would be even worse as Maven would then treat it as two different artifacts while they contain the same classes. So only the first one on the classpath will be used. But I understand the worries and that's why I asked if it known to be used by anything other than m-compiler-p. If it isn't, and as we control m-compiler-p, there is no problem doing backwards incompatible changes. I might be remembering wrong, but I think that someone proposed moving the code to Apache Maven space and we could do the changes then instead. Just to shed some light on why I think we should do this: In some cases there aren't an error message returned by the compiler even though the compilation did/should fail. Such a case is IIRC if -Werror is configured, where compilation fails on warnings as well. Today the plexus-compiler handles this by adding a fake error message so that m-compiler-p will see an error message in the returned list of messages. And then fail the plugin execution. Just not a pretty solution which is actually currently buggy (stopped working in v1.9.2 of plexus-compiler e.g.). /Anders I'm not trying to convince you do to this for plexus compiler, but I hate to leave an email thread lying about that gives the impression that bumping the version number a long distance is all it takes. /Anders On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier aherit...@gmail.com wrote: +1 to bump the compiler to 3.0 with this change On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy ol...@apache.org wrote: So as no objections it's now merged. I bumped plexus-compiler version to 2.0-SNAPSHOT. As maven-compiler-plugin has a lot of changes (including incremental stuff) I wonder about bump version to 3.0-SNAPSHOT ? 2012/10/18 Olivier Lamy ol...@apache.org: just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please,
Re: PLXCOMP-1 and improving compiler-message parsing
just FYI I have created a branch here https://github.com/sonatype/plexus-compiler/tree/PLXCOMP-1 This supports 1.5 and javax.tools if available in the user env. I have noticed some perf degradation testing the pull request https://github.com/sonatype/plexus-compiler/pull/6. Using JavaCompiler compiler = ToolProvider.getSystemJavaCompiler(); for each compilation is very slower. So I have tried to mimic similar stuff as done with current Javacc (the reuseStrategy see http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#compilerReuseStrategy ). NOTE that's a *very* basic pool mechanism :-). As I have no idea if the compiler is threadsafe or not (it's not documented to be thread safe in javadoc but at least javadoc samples says it can be reused for future compilation). Tests on my env (osx + java 1.6.0_37) looks to say yes. In compiler plugin (not committed yet), I have added a flag to disable use of javax.tools usage (as it if that breaks on some os/jdk users will be able to disable it even if that's detected to be usable) WDYT ? 2012/10/1 Stephen Connolly stephen.alan.conno...@gmail.com: On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For
Re: PLXCOMP-1 and improving compiler-message parsing
On 28 September 2012 18:15, John Casey jdca...@commonjava.org wrote: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. There is the Toolchains issue. At present, AFAIK we can use Toolchains to run Maven with Java 1.6 and compile with Java 1.3. Surefire supports running tests via toolchains down to Java 1.3 IIRC If we are doing something that makes this kind of thing impossible *even via toolchains* then my feeling is that I am -1. If we can find a way (more indirection please, it solves all problems don't you know) to allow this to work *and* retain toolchains support for compiling with JDK 1.3 then +1. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/**plexus-compiler/pull/6https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/**browse/PLXCOMP-1http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey --**--** - To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey --**--**- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**orgdev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PLXCOMP-1 and improving compiler-message parsing
If I try to take a few steps back from this issue; I wish there was some way we could just leave the old parsing logic as-is for 1.5 and make a cleaner fork that'd be used for 1.6, maybe even some system that could be extended to apply for 1.7 1.8 too ? I'm thinking along the lines of what I did in surefire; there is the classic junit4 provider and the much more modernized junit 4.7+ provider; which arguably has left the realm of the classic junit4 runner totally. I'm not sure this is feasible, but could we somehow fork 1.6 support in a module and just ditch 1.5 entirely at some point in the future ? Kristian 2012/9/28 John Casey jdca...@commonjava.org: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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
Re: PLXCOMP-1 and improving compiler-message parsing
Hi, Perso, I like the idea about using such pattern. That sounds a reasonable way to move forward. 2012/9/29 Kristian Rosenvold kristian.rosenv...@gmail.com: If I try to take a few steps back from this issue; I wish there was some way we could just leave the old parsing logic as-is for 1.5 and make a cleaner fork that'd be used for 1.6, maybe even some system that could be extended to apply for 1.7 1.8 too ? I'm thinking along the lines of what I did in surefire; there is the classic junit4 provider and the much more modernized junit 4.7+ provider; which arguably has left the realm of the classic junit4 runner totally. I'm not sure this is feasible, but could we somehow fork 1.6 support in a module and just ditch 1.5 entirely at some point in the future ? Kristian 2012/9/28 John Casey jdca...@commonjava.org: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PLXCOMP-1 and improving compiler-message parsing
And that could be nice to such new components hosted @asf (maybe in maven-shared) 2012/9/29 Olivier Lamy ol...@apache.org: Hi, Perso, I like the idea about using such pattern. That sounds a reasonable way to move forward. 2012/9/29 Kristian Rosenvold kristian.rosenv...@gmail.com: If I try to take a few steps back from this issue; I wish there was some way we could just leave the old parsing logic as-is for 1.5 and make a cleaner fork that'd be used for 1.6, maybe even some system that could be extended to apply for 1.7 1.8 too ? I'm thinking along the lines of what I did in surefire; there is the classic junit4 provider and the much more modernized junit 4.7+ provider; which arguably has left the realm of the classic junit4 runner totally. I'm not sure this is feasible, but could we somehow fork 1.6 support in a module and just ditch 1.5 entirely at some point in the future ? Kristian 2012/9/28 John Casey jdca...@commonjava.org: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands,
Re: PLXCOMP-1 and improving compiler-message parsing
+1 I see no reason to fumble with that stuff on foreign realms. LieGrue, strub - Original Message - From: Olivier Lamy ol...@apache.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Saturday, September 29, 2012 3:53 PM Subject: Re: PLXCOMP-1 and improving compiler-message parsing And that could be nice to such new components hosted @asf (maybe in maven-shared) 2012/9/29 Olivier Lamy ol...@apache.org: Hi, Perso, I like the idea about using such pattern. That sounds a reasonable way to move forward. 2012/9/29 Kristian Rosenvold kristian.rosenv...@gmail.com: If I try to take a few steps back from this issue; I wish there was some way we could just leave the old parsing logic as-is for 1.5 and make a cleaner fork that'd be used for 1.6, maybe even some system that could be extended to apply for 1.7 1.8 too ? I'm thinking along the lines of what I did in surefire; there is the classic junit4 provider and the much more modernized junit 4.7+ provider; which arguably has left the realm of the classic junit4 runner totally. I'm not sure this is feasible, but could we somehow fork 1.6 support in a module and just ditch 1.5 entirely at some point in the future ? Kristian 2012/9/28 John Casey jdca...@commonjava.org: On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: PLXCOMP-1 and improving compiler-message parsing
+1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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
Re: PLXCOMP-1 and improving compiler-message parsing
On 9/28/12 12:08 PM, Mark Struberg wrote: +1 Imo this comes hand in hand with moving maven-core to 1.6 as well and a version bump to mvn-3.2.0 or even mvn-3.5.0 We might create a documentation page about Strategies for targeting older Java versions which outlines the animal-sniffer, etc LieGrue, strub I think the plugin could be a sort of advance guard for the core itself, since people can still use the core + the older version of the compiler plugin to run on 1.5... I wouldn't want to get mired in a discussion about when we're going to move the core up to 1.6, since that's a bit more work. - Original Message - From: John Casey jdca...@commonjava.org To: Maven Developers List dev@maven.apache.org Cc: Sent: Friday, September 28, 2012 6:53 PM Subject: PLXCOMP-1 and improving compiler-message parsing Hi everyone, There's a new patch to the plexus-compiler libraries which improves the parsing of the output messages, especially for annotation processing. Previously, a lot of non-error messages caused plexus-compiler (and thereby, Maven) to think a compilation error had occurred. The patch fixes this by using the javax.tools APIs to work with in-process compilation. The patch is here: https://github.com/sonatype/plexus-compiler/pull/6 The issue is here (it's been out there for a LONG time, as you can see: http://jira.codehaus.org/browse/PLXCOMP-1 The javax.tools APIs are JDK 1.6+ IIRC, so merging this patch would effectively drag the future of the maven-compiler-plugin up to requiring JDK 1.6. Personally, since JDK 1.5 has been out almost as long as I've been coding (well, not too far), I don't see the problem. Remember, we're not asking people to upgrade their production VM, only the build-time version...and we have documented strategies for targeting older VM versions successfully. We might look at strategies for degrading gracefully in case someone is using JDK 1.5, but IMO we need to be very careful about this. For instance, I wouldn't want people to wind up with unexplained, random new errors because they accidentally set their $PATH wrong. But maybe we could give them a large warning then switch over to forked-mode compilation in this case? I'd really hate to see this patch go unmerged because we're stuck supporting JDK 1.5...or if we do reject it on these grounds, maybe we need to talk about when it's reasonable to jump ship on 1.5 if not now? I'd LIKE to merge this patch, release plexus-compiler, and document how to use it as a plugin-level dependency...then make the move to 1.6 for the compiler plugin. Thoughts? -john -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) GitHub - http://github.com/jdcasey - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
