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