Good detective work, thanks! -Marshall
On 7/18/2016 5:19 PM, Richard Eckart de Castilho wrote: > The failures seem to have come from the Jenkins configuration. The job was set > to use the "system" JVM which on some build slaves appears to he a JRE > (running > Jenkins), not a JDK. So I changed the JVM setting in the job to "latest1.7". > > That fixes the "no compiler" problem. > > I don't see yet whether JaCoCo is also fixed now because we now hit the semver > enforcer failing due to the new CasIoUtils class. > > Cheers, > > -- Richard > >> On 18.07.2016, at 20:43, Richard Eckart de Castilho <[email protected]> wrote: >> >> I believe there are some problems with the build nodes. I don't think this is >> related to JaCoCo. >> >> Afaik JaCoCo uses a JVM agent to intercept classes during classloading and to >> inject coverage-measuring code. The results of this are written to a log >> during >> test execution and converted to a report upon build completion. >> >> First, I thought I could add excludes to the Maven JaCoCo configuration to >> avoid >> the problem with the duplicate SourceDocumentInformation. Now, I think these >> excludes may have to be added to the Jenkins configuration for JaCoCo. >> However, since I made that change to the Jenkins config, I think we had some >> unrelated problems with Jenkins. As a matter of fact, currently I even get >> a "service unavailable" message when trying to access Jenkins. >> >> Cheers, >> >> -- Richard >> >>> On 18.07.2016, at 19:13, Marshall Schor <[email protected]> wrote: >>> >>> I'm seeing failures when trying to run the maven-compiler-plug, which say >>> "No >>> compiler is provided in this environment". >>> >>> Anyone have a clue what's (sometimes) causing this? >>> >>> Also, I see for the output that the order of plugin running seems to run the >>> jacoco plugin before running the compile and tests. >>> >>> I thought the jacoco plugin would run after compile / tests in order to >>> pick up >>> the results of the testing? >>> >>> -Marshall >
