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 >>>>>> >> 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. >>>>>> >>>>> >>>>>> >>>>> 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.**org< >>>>>> dev-unsubscr...@maven.apache.org> >>>>>> >>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>> >>>>>> >>>>> >>>>>> >>>> >>>>>> ------------------------------**------------------------------**--------- >>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org< >>>>>> 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-unsubscribe@maven.apache.**org< >>>>>> 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, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> ----- >>>>> Arnaud Héritier >>>>> 06-89-76-64-24 >>>>> http://aheritier.net >>>>> Mail/GTalk: aherit...@gmail.com >>>>> Twitter/Skype : aheritier >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > 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, e-mail: dev-h...@maven.apache.org
