> 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
