db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: fiixing JaCoCo, was: need help configuring Jenkins
Date Mon, 04 Dec 2017 09:41:54 GMT
Rick Hillegas <rick.hillegas@gmail.com> writes:

> On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
>> Knut Anders Hatlen <knut.hatlen@oracle.com> writes:
>>> Rick Hillegas <rick.hillegas@gmail.com> writes:
>>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>>> Rick Hillegas <rick.hillegas@gmail.com> 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
>>>>> 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
>>>>> fetched jar files from a committer's home directory. The Derby-JaCoCo
>>>>> job fetched the jar files from Maven, which sounded more maintainable
>>>>> 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?

Hi Rick,

I think they use the ordinary policy files, but the extra permissions
needed for JaCoCo are guarded by the jacoco.active system property. For

permission java.io.FilePermission "${jacoco.active}${user.dir}${/}*", "read, write";

When JaCoCo is active, the jacoco.active property is set to the empty
string, so that the above rule becomes equivalent to

permission java.io.FilePermission "${user.dir}${/}*", "read, write";

and thereby becomes active.

The code that sets the jacoco.active property seems to be located in
BaseTestCase and SecurityManagerSetup.

Knut Anders

View raw message