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