The issue is that there are classes which generate a different signature
when compiled with the Java 8 RT vs when compiled with the Java 7 RT.
+1
I think what we - as a community - are learning is that we no longer
have the luxury of compiling with a newer JDK against an older
On 1 December 2014 at 09:23, Mark Struberg strub...@yahoo.de wrote:
The issue is that there are classes which generate a different signature
when compiled with the Java 8 RT vs when compiled with the Java 7 RT.
+1
I think what we - as a community - are learning is that we no longer
Hi Paul!
Txs, this is definitely one possible direction in which we could aim.
LieGrue,
strub
On Saturday, 29 November 2014, 11:18, Paul Moloney pmoloney...@gmail.com
wrote:
Hi
I had written this rule for the enforcer plugin which actually checks the
label of jdk version in
I think selected JDK should also be used to resolve ${java.home} in
system-scoped dependencies. Which I think means concept of project
target JDK should be directly supported by Maven itself.
--
Regards,
Igor
On 2014-12-01, 4:23, Mark Struberg wrote:
The issue is that there are classes which
Op Mon, 01 Dec 2014 10:23:09 +0100 schreef Mark Struberg
strub...@yahoo.de:
The issue is that there are classes which generate a different signature
when compiled with the Java 8 RT vs when compiled with the Java 7 RT.
+1
I think what we - as a community - are learning is that we no
On 1 Dec 2014, at 22:23, Mark Struberg wrote:
2.) enhance the ToolchainManager to let lookup configured Toolchains and use
this in maven-compiler-plugin and maven-test-plugin to use a 'preferred'
Toolchain version. E.g. if target=1.7 is defined it should try to resolve
this Toolchain.
As
+1
Regards,
Hervé
Le lundi 1 décembre 2014 07:54:56 Baptiste Mathus a écrit :
+1.
Though I quite also like the comment about having some form of M on the
chest (say like a superman S), but I'm late to the train here.
Le 28 nov. 2014 10:38, Dennis Lundberg denn...@apache.org a écrit :
