Thanks Olivier! It should be rocking now, hopefully.
/Anders
On Thu, Nov 8, 2012 at 3:34 PM, Olivier Lamy wrote:
> done
>
> 2012/11/8 Anders Hammar :
> > 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 Compiler
done
2012/11/8 Anders Hammar :
> 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
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
I've added comments to the pull request itself.
/Anders
On Sun, Oct 28, 2012 at 10:42 PM, Olivier Lamy 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
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 :
> I think this change makes sense.
> But I know at le
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 :
>> Changing the version number to 2.0 is not good enough to make
>> incompatible
> 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 a
On Fri, Oct 19, 2012 at 7:16 AM, Anders Hammar 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.compi
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 rathe
+1 to bump the compiler to 3.0 with this change
On Fri, Oct 19, 2012 at 12:30 PM, Olivier Lamy 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 v
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 :
> just FYI I have created a branch here
> https://github.com/s
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 com
On 28 September 2012 18:15, John Casey 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
+1 I see no reason to fumble with that stuff on foreign realms.
LieGrue,
strub
- Original Message -
> From: Olivier Lamy
> To: Maven Developers List
> Cc:
> Sent: Saturday, September 29, 2012 3:53 PM
> Subject: Re: PLXCOMP-1 and improving compiler-message parsin
And that could be nice to such new components hosted @asf (maybe in
maven-shared)
2012/9/29 Olivier Lamy :
> Hi,
> Perso, I like the idea about using such pattern.
> That sounds a reasonable way to move forward.
>
> 2012/9/29 Kristian Rosenvold :
>> If I try to take a few steps back from this issu
Hi,
Perso, I like the idea about using such pattern.
That sounds a reasonable way to move forward.
2012/9/29 Kristian Rosenvold :
> 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'
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
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
Li
+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
19 matches
Mail list logo
