You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@maven.apache.org by John Casey <jd...@commonjava.org> on 2012/09/28 18:53:12 UTC

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


The issue is here (it's been out there for a LONG time, as you can see:

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

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Mark Struberg <st...@yahoo.de>.

+1 I see no reason to fumble with that stuff on foreign realms.

LieGrue,
strub




----- Original Message -----
> From: Olivier Lamy <ol...@apache.org>
> To: Maven Developers List <de...@maven.apache.org>
> Cc: 
> Sent: Saturday, September 29, 2012 3:53 PM
> Subject: Re: PLXCOMP-1 and improving compiler-message parsing
> 
> And that could be nice to such new components hosted @asf (maybe in
> maven-shared)
> 
> 2012/9/29 Olivier Lamy <ol...@apache.org>:
>>  Hi,
>>  Perso, I like the idea about using such pattern.
>>  That sounds a reasonable way to move forward.
>> 
>>  2012/9/29 Kristian Rosenvold <kr...@gmail.com>:
>>>  If I try to take a few steps back from this issue; I wish there was
>>>  some way we could just leave the old parsing logic as-is for 1.5 and
>>>  make a cleaner fork that'd be used for 1.6, maybe even some system
>>>  that could be extended to apply for 1.7 & 1.8 too ? I'm 
> thinking along
>>>  the lines of what I did in surefire; there is the classic junit4
>>>  provider and the much more modernized junit 4.7+ provider; which
>>>  arguably has left the realm of the classic junit4 runner totally.
>>> 
>>>  I'm not sure this is feasible, but could we somehow fork 1.6 
> support
>>>  in a module and just ditch 1.5 entirely at some point in the future ?
>>> 
>>>  Kristian
>>> 
>>> 
>>>  2012/9/28 John Casey <jd...@commonjava.org>:
>>>>  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.
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>  ----- Original Message -----
>>>>>> 
>>>>>>  From: John Casey <jd...@commonjava.org>
>>>>>>  To: Maven Developers List <de...@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
>>>>>> 
>>>>>> 
>>>>>>  The issue is here (it's been out there for a LONG time, 
> as you can see:
>>>>>> 
>>>>>>  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
>>>>>>  For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> 
>>>>> 
>>>>> 
> ---------------------------------------------------------------------
>>>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>>  For additional commands, e-mail: dev-help@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
>>>>  For additional commands, e-mail: dev-help@maven.apache.org
>>>> 
>>> 
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>  For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Olivier Lamy <ol...@apache.org>.

And that could be nice to such new components hosted @asf (maybe in
maven-shared)

2012/9/29 Olivier Lamy <ol...@apache.org>:
> Hi,
> Perso, I like the idea about using such pattern.
> That sounds a reasonable way to move forward.
>
> 2012/9/29 Kristian Rosenvold <kr...@gmail.com>:
>> If I try to take a few steps back from this issue; I wish there was
>> some way we could just leave the old parsing logic as-is for 1.5 and
>> make a cleaner fork that'd be used for 1.6, maybe even some system
>> that could be extended to apply for 1.7 & 1.8 too ? I'm thinking along
>> the lines of what I did in surefire; there is the classic junit4
>> provider and the much more modernized junit 4.7+ provider; which
>> arguably has left the realm of the classic junit4 runner totally.
>>
>> I'm not sure this is feasible, but could we somehow fork 1.6 support
>> in a module and just ditch 1.5 entirely at some point in the future ?
>>
>> Kristian
>>
>>
>> 2012/9/28 John Casey <jd...@commonjava.org>:
>>> 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.
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>>
>>>>> From: John Casey <jd...@commonjava.org>
>>>>> To: Maven Developers List <de...@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
>>>>>
>>>>>
>>>>> The issue is here (it's been out there for a LONG time, as you can see:
>>>>>
>>>>> 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
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@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
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Olivier Lamy <ol...@apache.org>.

Hi,
Perso, I like the idea about using such pattern.
That sounds a reasonable way to move forward.

2012/9/29 Kristian Rosenvold <kr...@gmail.com>:
> If I try to take a few steps back from this issue; I wish there was
> some way we could just leave the old parsing logic as-is for 1.5 and
> make a cleaner fork that'd be used for 1.6, maybe even some system
> that could be extended to apply for 1.7 & 1.8 too ? I'm thinking along
> the lines of what I did in surefire; there is the classic junit4
> provider and the much more modernized junit 4.7+ provider; which
> arguably has left the realm of the classic junit4 runner totally.
>
> I'm not sure this is feasible, but could we somehow fork 1.6 support
> in a module and just ditch 1.5 entirely at some point in the future ?
>
> Kristian
>
>
> 2012/9/28 John Casey <jd...@commonjava.org>:
>> 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.
>>
>>
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>>
>>>> From: John Casey <jd...@commonjava.org>
>>>> To: Maven Developers List <de...@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
>>>>
>>>>
>>>> The issue is here (it's been out there for a LONG time, as you can see:
>>>>
>>>> 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
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Kristian Rosenvold <kr...@gmail.com>.

If I try to take a few steps back from this issue; I wish there was
some way we could just leave the old parsing logic as-is for 1.5 and
make a cleaner fork that'd be used for 1.6, maybe even some system
that could be extended to apply for 1.7 & 1.8 too ? I'm thinking along
the lines of what I did in surefire; there is the classic junit4
provider and the much more modernized junit 4.7+ provider; which
arguably has left the realm of the classic junit4 runner totally.

I'm not sure this is feasible, but could we somehow fork 1.6 support
in a module and just ditch 1.5 entirely at some point in the future ?

Kristian


2012/9/28 John Casey <jd...@commonjava.org>:
> 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.
>
>
>>
>>
>>
>>
>> ----- Original Message -----
>>>
>>> From: John Casey <jd...@commonjava.org>
>>> To: Maven Developers List <de...@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
>>>
>>>
>>> The issue is here (it's been out there for a LONG time, as you can see:
>>>
>>> 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
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Anders Hammar <an...@hammar.net>.

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 <an...@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 <an...@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 <an...@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 <
> >> aheritier@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 <olamy@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 <st...@gmail.com>:
> >> >>>>>>> >> On 28 September 2012 18:15, John Casey <
> jdcasey@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 <jd...@commonjava.org>
> >> >>>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
> >> >>>>>>> >>>>> For additional commands, e-mail:
> dev-help@maven.apache.org
> >> >>>>>>> >>>>>
> >> >>>>>>> >>>>>
> >> >>>>>>> >>>>
> >> >>>>>>>
> >>
> ------------------------------**------------------------------**---------
> >> >>>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.
> **org<
> >> >>>>>>> dev-unsubscribe@maven.apache.org>
> >> >>>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
> >> >>>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> --
> >> >>>>>> -----
> >> >>>>>> Arnaud Héritier
> >> >>>>>> 06-89-76-64-24
> >> >>>>>> http://aheritier.net
> >> >>>>>> Mail/GTalk: aheritier@gmail.com
> >> >>>>>> Twitter/Skype : aheritier
> >> >>>>>
> >> >>>>>
> ---------------------------------------------------------------------
> >> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>>
> >> >>>>
> >> >>>>
> ---------------------------------------------------------------------
> >> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >> >>>>
> >> >>>
> >> >>>
> ---------------------------------------------------------------------
> >> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >> > For additional commands, e-mail: dev-help@maven.apache.org
> >> >
> >>
>
>
>
> --
> Olivier Lamy
> Talend: http://coders.talend.com
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Olivier Lamy <ol...@apache.org>.

done

2012/11/8 Anders Hammar <an...@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 <an...@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 <an...@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 <
>> aheritier@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 <st...@gmail.com>:
>> >>>>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>> >>>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>> >>>>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>> >>>>>
>> >>>>>>> >>>>>
>> >>>>>>> >>>>
>> >>>>>>>
>> ------------------------------**------------------------------**---------
>> >>>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>> >>>>>>> dev-unsubscribe@maven.apache.org>
>> >>>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>> >>>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>>>
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> --
>> >>>>>> -----
>> >>>>>> Arnaud Héritier
>> >>>>>> 06-89-76-64-24
>> >>>>>> http://aheritier.net
>> >>>>>> Mail/GTalk: aheritier@gmail.com
>> >>>>>> Twitter/Skype : aheritier
>> >>>>>
>> >>>>> ---------------------------------------------------------------------
>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: dev-help@maven.apache.org
>> >
>>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Anders Hammar <an...@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 <an...@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 <an...@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 <
> aheritier@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 <st...@gmail.com>:
> >>>>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
> >>>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
> >>>>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>> >>>>>
> >>>>>>> >>>>>
> >>>>>>> >>>>
> >>>>>>>
> ------------------------------**------------------------------**---------
> >>>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
> >>>>>>> dev-unsubscribe@maven.apache.org>
> >>>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
> >>>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> -----
> >>>>>> Arnaud Héritier
> >>>>>> 06-89-76-64-24
> >>>>>> http://aheritier.net
> >>>>>> Mail/GTalk: aheritier@gmail.com
> >>>>>> Twitter/Skype : aheritier
> >>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Anders Hammar <an...@hammar.net>.

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 <an...@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 <ah...@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 <st...@gmail.com>:
>>>>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>>>>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>> >>>>>
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> ------------------------------**------------------------------**---------
>>>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>>>>>>> dev-unsubscribe@maven.apache.org>
>>>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>>>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> -----
>>>>>> Arnaud Héritier
>>>>>> 06-89-76-64-24
>>>>>> http://aheritier.net
>>>>>> Mail/GTalk: aheritier@gmail.com
>>>>>> Twitter/Skype : aheritier
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Olivier Lamy <ol...@apache.org>.

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 <an...@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 <ah...@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 <st...@gmail.com>:
>>>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>>>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>> >>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>>>>>> dev-unsubscribe@maven.apache.org>
>>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -----
>>>>> Arnaud Héritier
>>>>> 06-89-76-64-24
>>>>> http://aheritier.net
>>>>> Mail/GTalk: aheritier@gmail.com
>>>>> Twitter/Skype : aheritier
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by 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 <an...@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 <ah...@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 <st...@gmail.com>:
>>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>
>>>>> ------------------------------**------------------------------**---------
>>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>>>>> dev-unsubscribe@maven.apache.org>
>>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> -----
>>>> Arnaud Héritier
>>>> 06-89-76-64-24
>>>> http://aheritier.net
>>>> Mail/GTalk: aheritier@gmail.com
>>>> Twitter/Skype : aheritier
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Anders Hammar <an...@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 <ah...@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 <st...@gmail.com>:
>>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>> >>>>>
>>>> >>>>>
>>>> >>>>
>>>> ------------------------------**------------------------------**---------
>>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>>>> dev-unsubscribe@maven.apache.org>
>>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> -----
>>> Arnaud Héritier
>>> 06-89-76-64-24
>>> http://aheritier.net
>>> Mail/GTalk: aheritier@gmail.com
>>> Twitter/Skype : aheritier
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Benson Margulies <bi...@gmail.com>.

On Fri, Oct 19, 2012 at 7:16 AM, Anders Hammar <an...@hammar.net> wrote:
> Just a question regarding plexus-compiler: Is it known to be used by
> anything but the m-compiler-p? As we're bumping to v2.0, how about
> breaking backwards compatibility? I'm thinking that we should change
> the signature of Compiler.compile so that it doesn't just return a
> list of messages, but rather return the result of the compilation
> (together with a list of messages).
> (Also, I wouldn't mind changing the name of the CompilerError class to
> e.g. CompilerMessage.)

This component is so obscure that the following is perhaps not relevant, but ...

Changing the version number to 2.0 is not good enough to make
incompatible changes, due to the working of dependency resolution.
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.

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 <ah...@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 <st...@gmail.com>:
>>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>> >>>>>
>>> >>>>>
>>> >>>>
>>> ------------------------------**------------------------------**---------
>>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>>> dev-unsubscribe@maven.apache.org>
>>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>>
>> --
>> -----
>> Arnaud Héritier
>> 06-89-76-64-24
>> http://aheritier.net
>> Mail/GTalk: aheritier@gmail.com
>> Twitter/Skype : aheritier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Anders Hammar <an...@hammar.net>.

Just a question regarding plexus-compiler: Is it known to be used by
anything but the m-compiler-p? As we're bumping to v2.0, how about
breaking backwards compatibility? I'm thinking that we should change
the signature of Compiler.compile so that it doesn't just return a
list of messages, but rather return the result of the compilation
(together with a list of messages).
(Also, I wouldn't mind changing the name of the CompilerError class to
e.g. CompilerMessage.)

/Anders

On Fri, Oct 19, 2012 at 12:56 PM, Arnaud Héritier <ah...@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 <st...@gmail.com>:
>> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
>> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
>> >>>>>
>> >>>>>
>> >>>>
>> ------------------------------**------------------------------**---------
>> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
>> dev-unsubscribe@maven.apache.org>
>> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
>> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
>
> --
> -----
> Arnaud Héritier
> 06-89-76-64-24
> http://aheritier.net
> Mail/GTalk: aheritier@gmail.com
> Twitter/Skype : aheritier

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Arnaud Héritier <ah...@gmail.com>.

+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 <st...@gmail.com>:
> >> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
> >>>>> To: Maven Developers List <de...@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-unsubscribe@maven.apache.org>
> >>>>> For additional commands, e-mail: dev-help@maven.apache.org
> >>>>>
> >>>>>
> >>>>
> ------------------------------**------------------------------**---------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<
> dev-unsubscribe@maven.apache.org>
> >>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org>
> >>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
-----
Arnaud Héritier
06-89-76-64-24
http://aheritier.net
Mail/GTalk: aheritier@gmail.com
Twitter/Skype : aheritier

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Olivier Lamy <ol...@apache.org>.

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 <st...@gmail.com>:
>> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>>> To: Maven Developers List <de...@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<de...@maven.apache.org>
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>> ------------------------------**------------------------------**---------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@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<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by 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 <st...@gmail.com>:
> On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>>> To: Maven Developers List <de...@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<de...@maven.apache.org>
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@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<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>



-- 
Olivier Lamy
Talend: http://coders.talend.com
http://twitter.com/olamy | http://linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Stephen Connolly <st...@gmail.com>.

On 28 September 2012 18:15, John Casey <jd...@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 <jd...@commonjava.org>
>>> To: Maven Developers List <de...@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<de...@maven.apache.org>
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.**org<de...@maven.apache.org>
>> For additional commands, e-mail: dev-help@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<de...@maven.apache.org>
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by John Casey <jd...@commonjava.org>.

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.

>
>
>
>
> ----- Original Message -----
>> From: John Casey <jd...@commonjava.org>
>> To: Maven Developers List <de...@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
>>
>>
>> The issue is here (it's been out there for a LONG time, as you can see:
>>
>> 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
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@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
For additional commands, e-mail: dev-help@maven.apache.org

Re: PLXCOMP-1 and improving compiler-message parsing

Posted by Mark Struberg <st...@yahoo.de>.

+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




----- Original Message -----
> From: John Casey <jd...@commonjava.org>
> To: Maven Developers List <de...@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
> 
> 
> The issue is here (it's been out there for a LONG time, as you can see:
> 
> 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
> For additional commands, e-mail: dev-help@maven.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org