Op Mon, 14 Sep 2015 20:27:39 +0200 schreef Alan Bateman
:
On 14/09/2015 17:40, Robert Scholte wrote:
Hi,
On behalf of the Apache Maven team I'd like to ask for advice for
changing the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with Maven
*by defaul
On 09/14/2015 12:44 PM, Alan Bateman wrote:
On 14/09/2015 20:21, Stuart McCulloch wrote:
Yes, the issue is that ToolProvider.getSystemJavaCompiler() is
returning null when using the Jigsaw EA with Maven.
AFAICT this is because it’s now using the service loader mechanism
which is influenced
Github user Stephan202 closed the pull request at:
https://github.com/apache/maven/pull/40
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is en
Github user Stephan202 commented on the pull request:
https://github.com/apache/maven/pull/40#issuecomment-140189697
A variation on the proposed fix was merged in #58. So I'll close this PR.
(I'll also delete by branch/fork, but the diff can still be viewed in
[MNG-5786](https
On 14/09/2015 20:21, Stuart McCulloch wrote:
Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null
when using the Jigsaw EA with Maven.
AFAICT this is because it’s now using the service loader mechanism which is
influenced by the Thread’s context ClassLoader
That ma
Yes, the issue is that ToolProvider.getSystemJavaCompiler() is returning null
when using the Jigsaw EA with Maven.
AFAICT this is because it’s now using the service loader mechanism which is
influenced by the Thread’s context ClassLoader
The following patch to make sure Maven uses the system
On 14/09/2015 17:40, Robert Scholte wrote:
Hi,
On behalf of the Apache Maven team I'd like to ask for advice for
changing the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with
Maven *by default*, so right now when pointing JAVA_HOME to the latest
JDK9 ver
Github user lamyaa commented on the pull request:
https://github.com/apache/maven-surefire/pull/98#issuecomment-140153614
@Tibor17 It seems that we have a check for elapsed time being null in
TestSetRunListerner.java so we never instantiate WrappedReportEntry with a null
elapsed time.
Github user lamyaa commented on the pull request:
https://github.com/apache/maven-surefire/pull/98#issuecomment-140152959
@Tibor17
``createTestSuiteElement( ppw, testSetReportEntry, testSetStats,
reportNameSuffix, testSetReportEntry.elapsedTimeAsString() )`` does fix the
issue.
Github user lamyaa commented on the pull request:
https://github.com/apache/maven-surefire/pull/98#issuecomment-140148135
@Tibor17 I tried just changing the last parameter like you suggested:
``createTestSuiteElement( ppw, testSetReportEntry, testSetStats,
reportNameSuffix, testSet
Hi,
On behalf of the Apache Maven team I'd like to ask for advice for changing
the JavaxToolsCompiler[1]
This implementation is used when java code is being compiled with Maven
*by default*, so right now when pointing JAVA_HOME to the latest JDK9
version builds will fail.
There are other wa
Github user jvanzyl commented on the pull request:
https://github.com/apache/maven/pull/58#issuecomment-140046053
@fbricon, @dsyer's logic was also integrated into the Maven Wrapper. I'll
release the Maven Wrapper today with that fix.
---
If your project is set up for it, you can rep
12 matches
Mail list logo
