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.
target=1.7 in both cases.
There are 2 options: either use javac -bootclasspath and point it to
the 'correct' rt.jar + other jdk libs, or just switch the whole
environment.
Roberts suggestion was to use the Maven Toolchain
system:http://maven.apache.org/plugins/maven-toolchains-plugin/
ifferent bytecode
than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.
There are 2 options: either use javac -bootclasspath and point it to the
'correct' rt.jar + other jdk libs, or just switch the whole environment.
Roberts suggestion was to use the Maven
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
> wrote:
> > Hi
>
> I had written this rule for the enforcer plugin which actually checks the
> label of jdk version in toolchains against out
rn new JDK16RTUser();
> >>}
> >> }
> >>
> >> public static IRTUser getInstance() { return instance; }
> >>
> >>This approach has worked fine for me on multiple occasions.
> >>
> >>
> >>Jochen
> >>
&g
gt;> over at Apache OpenWebBeans:
>>>
>>> https://issues.apache.org/jira/browse/OWB-952
>>>
>>> As a short summary: the classes provided in rt.jar of Java8 are slightly
>>> different than the ones from Java7 and 6. Similar big differences have been
&
rovided in rt.jar of Java8 are slightly
> different than the ones from Java7 and 6. Similar big differences have been
> seen in the Java4 to 5 transition.
> > Thus if you compile your project with Java8 you might get different
> bytecode than when compiling with Java7 JDK.
ransition.
> Thus if you compile your project with Java8 you might get different bytecode
> than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.
>
> There are 2 options: either use javac -bootclasspath and point it to the
> 'correct' rt.j
Hi
I had written this rule for the enforcer plugin which actually checks the
label of jdk version in toolchains against output of javc --version. It
works for my limited scenario @work and definetely requires more attention
to cope with non oracle compilers and the apache way.
https://github.com/
Hi!
> This lets you selectively forbid certain methods
The problem is that the methods used are perfectly fine. The API methods used
in our program do exist even in Java6. But they get coerced to different
methods when compiling with Java8. And those new methods do not exist in Java7
and ol
There is also a very cool tool from the Lucene land, written by Uwe Schindler --
https://code.google.com/p/forbidden-apis/
This lets you selectively forbid certain methods from your codebase
(and the default list of forbidden methods has a strong rationale to
be discouraged -- locale-sensitive me
On Thursday, 27 November 2014, Mark Derricutt wrote:
> On 28 Nov 2014, at 10:32, Igor Fedorenko wrote:
>
> > Out of curiosity, why do you want to get exactly the same bytecode? Does
> > the code compiled with java8 not work under java7?
>
> Mostly - it's due to method signature resolution. For i
On 28 Nov 2014, at 10:32, Igor Fedorenko wrote:
> Out of curiosity, why do you want to get exactly the same bytecode? Does
> the code compiled with java8 not work under java7?
Mostly - it's due to method signature resolution. For instance in the JDK 5 ->
6 change, some functions that used to ta
ces have been
> seen in the Java4 to 5 transition.
> > Thus if you compile your project with Java8 you might get different
> bytecode than when compiling with Java7 JDK. Even if you use target=1.7 in
> both cases.
> >
> > There are 2 options: either use javac -bootclassp
different bytecode
than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.
There are 2 options: either use javac -bootclasspath and point it to the
'correct' rt.jar + other jdk libs, or just switch the whole environment.
Roberts suggestion was to use the Maven
have been
seen in the Java4 to 5 transition.
Thus if you compile your project with Java8 you might get different bytecode
than when compiling with Java7 JDK. Even if you use target=1.7 in both cases.
There are 2 options: either use javac -bootclasspath and point it to the
'correct&#x
(was: MNG-1303)
Project: Maven 2.x Surefire Plugin (was: Maven 2)
> surefire should include bootclasspath when running tests
>
>
> Key: MSUREFIRE-5
> URL: http://jira.codehaus.org/browse/MSUREFIRE-5
: jira (was: Maven)
Key: MCOMPILER-20 (was: MNG-973)
Project: Maven 2.x Compiler Plugin (was: Maven 2)
> add bootclasspath support to forked java compiler
> -
>
> Key: MCOMPILER-20
> URL: http://ji
[ http://jira.codehaus.org/browse/MNG-1303?page=all ]
Jason van Zyl closed MNG-1303:
--
Resolution: Fixed
This test case now works.
> surefire should include bootclasspath when running te
include bootclasspath when running tests
>
>
> Key: MNG-1303
> URL: http://jira.codehaus.org/browse/MNG-1303
> Project: Maven 2
> Type: Bug
> Components: maven-surefire-plugin
> Versi
bootclasspath support
-
Key: MPASPECTJ-22
URL: http://jira.codehaus.org/browse/MPASPECTJ-22
Project: maven-aspectj-plugin
Type: Wish
Versions: 3.2
Reporter: Shinobu Kawai Yoshida
Priority: Minor
It would be great if the plugin
[ http://jira.codehaus.org/browse/MNG-973?page=all ]
John Casey updated MNG-973:
---
Fix Version: (was: 2.0.1)
2.0.2
> add bootclasspath support to forked java compiler
> -
>
>
test
case, but since it dramatically changes the classloading strategy for surefire,
I wanted jason to take a look at it.
> surefire should include bootclasspath when running tests
>
>
> Key: MNG-1303
>
uld include bootclasspath when running tests
>
>
> Key: MNG-1303
> URL: http://jira.codehaus.org/browse/MNG-1303
> Project: Maven 2
> Type: Bug
> Components: maven-surefire-plugin
> V
.grasgxl.core.ConfigurationLoader.load(ConfigurationLoader.java:107)
Worked properly with Maven 1.
Summary: surefire should include bootclasspath when running tests
(was: Parsing XML document commons-digester fails in testcase)
the fix for this is to have the bootclasspath included in the
[ http://jira.codehaus.org/browse/MNG-973?page=all ]
Brett Porter updated MNG-973:
-
Fix Version: 2.0-beta-3
> add bootclasspath support to forked java compiler
> -
>
> Key: MNG-973
&g
add bootclasspath support to forked java compiler
-
Key: MNG-973
URL: http://jira.codehaus.org/browse/MNG-973
Project: Maven 2
Type: Improvement
Components: maven-compiler-plugin
Reporter: Brett Porter
this can
On Thu, 2003-12-04 at 12:58, Alain Javier Guarnieri del Gesu wrote:
> How does one specify the the bootclasspath to the java task? I don't
> see it in the java plugin code. I've hard coded my custom
> bootclasspath into a copy of the plugin.
Stop cross-posting between th
How does one specify the the bootclasspath to the java task? I don't
see it in the java plugin code. I've hard coded my custom
bootclasspath into a copy of the plugin.
Even better than setting a bootclasspath would be the ability to
prepend jars to the bootclasspath specified by javac.
29 matches
Mail list logo
