On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
Knut Anders Hatlen <[email protected]> writes:
Rick Hillegas <[email protected]> writes:
On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
Rick Hillegas <[email protected]> writes:
I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
JaCoCo jars at
https://urldefense.proofpoint.com/v2/url?u=http-3A__people.apache.org_-7Erhillegas_derby_jacoco-2Djars_&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=ZhaPG5oM4BGrJfVvjLS03y6iz4nvtBip_vUHOgTHkhI&e=.
Let's see if that helps.
Does anyone know why we also have a Derby-JaCoCo job (also broken)?
Why are we running JaCoCo twice and with different scripts?
Hi Rick,
I did some maintenance on the Derby-JaCoCo job some years ago, after it
had broken when we had moved to a newer Java version which was not
supported by the JaCoCo version we were using.
I remember that we had two jobs at that time too. Don't know why we had
two, though. I left the Derby-trunk-JaCoCo job alone, because it
appeared to be abandoned (it was disabled, I think), and also because it
fetched jar files from a committer's home directory. The Derby-JaCoCo
job fetched the jar files from Maven, which sounded more maintainable as
it allowed others than that one committer to make updates, if required.
I was actually planning to delete the Derby-trunk-JaCoCo job after a
while if the Derby-JaCoCo proved to be stable. But apparently I forgot.
Thanks, Knut. Sounds like we should retire Derby-trunk-JaCoCo and
figure out how to get Derby-JaCoCo to fetch the correct version of the
JaCoCo jars.
As a first step, I've updated Derby-JaCoCo to use the latest version of
JaCoCo (0.7.9). I did this by updating the following variables in the
build section of the configuration:
jacoco_version=0.7.9
jacoco_zip_sha1=1d56a66be0f4a6b529d8f983ab65cc77a52cccb6
jacocoant_sha1=87aa22de3854fd5a43e37a17c4b245b01a46de93
jacocoagent_sha1=a6ac9cca89d889222a40dab9dd5039bfd22a4cff
I had to download the JaCoCo zip file locally and extract it to
calculate the SHA1 checksums of the zip file and the two jar files we
need from it. The checksums are used by the build script to check if we
already have the right version, or if we have to download it from Maven.
I've kicked off a build, and it has already passed the point where it
failed before, so maybe that's all that was needed. Let's see what
happens...
The build job completed and produced a coverage report, so there is
improvement. 10 tests failed, though, so the job is still marked as
"unstable".
Thanks, Knut. The failures all result from a missing FilePermission
under DropDatabaseSetup while checking for the existence of a directory
before deleting it. The tests work standalone on my machine. Do you
remember if the JaCoCo test runs have their own security policy, which
might need to be updated?
Thanks,
-Rick
