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 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 >> > >>
-- 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
