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 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
