You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Rick Hillegas <ri...@gmail.com> on 2017/11/05 15:52:15 UTC
need help configuring Jenkins
I don't seem to know how to configure the Jenkins trunk build to use
Java 9. I tried adjusting the Tool Environment section, but that had no
effect. In the Build Environment tab I see a dropdown for specifying the
Ant version. But I don't see a dropdown for specifying the JDK version.
My casual googling turns up responses which don't correspond to the
layout of our Jenkins tabs.
Does anyone know how to do this?
Thanks,
-Rick
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@gmail.com> writes:
> On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
>> Knut Anders Hatlen <kn...@oracle.com> writes:
>>
>>> Rick Hillegas <ri...@gmail.com> writes:
>>>
>>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>>> Rick Hillegas <ri...@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 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?
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
example:
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
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/23/17 3:39 AM, Knut Anders Hatlen wrote:
> Knut Anders Hatlen <kn...@oracle.com> writes:
>
>> Rick Hillegas <ri...@gmail.com> writes:
>>
>>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>>> Rick Hillegas <ri...@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 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
>
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Knut Anders Hatlen <kn...@oracle.com> writes:
> Rick Hillegas <ri...@gmail.com> writes:
>
>> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas <ri...@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 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".
--
Knut Anders
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@gmail.com> writes:
> On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
>> Rick Hillegas <ri...@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 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...
--
Knut Anders
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/22/17 12:56 AM, Knut Anders Hatlen wrote:
> Rick Hillegas <ri...@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 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.
Cheers,
-Rick
>
>> See
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=wulacnvwG-OWc5lbUU9q382NzVuIur7Z7LVngjcHYPU&e=
>>
>> and
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2Dtrunk-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=YOFIV1NAlpMLVIwmKggAqSvt93XoNP1PMcQU_jPbBgo&e=
>>
>> Thanks,
>> -Rick
Re: fiixing JaCoCo, was: need help configuring Jenkins
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@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 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.
> See
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=wulacnvwG-OWc5lbUU9q382NzVuIur7Z7LVngjcHYPU&e=
>
> and
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__builds.apache.org_view_All_job_Derby-2Dtrunk-2DJaCoCo_configure&d=DwIDaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=mcFajTlbkIJ-DV-XHLk2TiSMDFfBhxQNXM5OBfEvYQ0&m=Otq7uQ72PfDMCJ4CD06LeG6bH0QqiepAX8rdSDsPTsM&s=YOFIV1NAlpMLVIwmKggAqSvt93XoNP1PMcQU_jPbBgo&e=
>
> Thanks,
> -Rick
--
Knut Anders
fiixing JaCoCo, was: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
I have updated the Derby-trunk-JaCoCo configuration to use the 0.7.9
JaCoCo jars at http://people.apache.org/~rhillegas/derby/jacoco-jars/.
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? See
https://builds.apache.org/view/All/job/Derby-JaCoCo/configure
and
https://builds.apache.org/view/All/job/Derby-trunk-JaCoCo/configure
Thanks,
-Rick
On 11/7/17 4:19 PM, Rick Hillegas wrote:
> On 11/6/17 5:06 PM, Rick Hillegas wrote:
>> On 11/5/17 7:36 PM, Bryan Pendleton wrote:
>>>>> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
>>>>> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>>>> If I understand that script, our JaCoCo runs rely on an old JaCoCo
>>>> version
>>>> cached on Kristian's Apache website. Here are some things we could do:
>>>>
>>>> 1) Ask Kristian to upgrade the JaCoCo version in his cache.
>>>>
>>>> 2) Cache a newer version on my Apache website and tweak the script
>>>> accordingly.
>>> Either one of those seems fine to me.
>>>
>>> If you fetch the newest version of the JaCoCo jars and put them on
>>> your Apache site,
>> I have copied the latest 0.7.9 artifacts to the
>> public_html/derby/jacoco-jars directory of my apache account by
>> sftping to minotaur.apache.org. But the artifacts are not visible at
>> people.apache.org/~rhillegas and the directory tree there differs
>> from the one on minotaur. I'm confused. I thought that all the apache
>> machines shared the same account space. I guess it's time for another
>> lesson from infra. Stay tuned...
> Ok, the new jars are now visible from people.apache.org. The two
> machines no longer share an account space.
>>> I'd be glad to fiddle the Jenkins configuration and see if it fixes
>>> the problem.
>>>
>>> thanks,
>>>
>>> bryan
>>>
>>
>
Re: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/6/17 5:06 PM, Rick Hillegas wrote:
> On 11/5/17 7:36 PM, Bryan Pendleton wrote:
>>>> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
>>>> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>>> If I understand that script, our JaCoCo runs rely on an old JaCoCo
>>> version
>>> cached on Kristian's Apache website. Here are some things we could do:
>>>
>>> 1) Ask Kristian to upgrade the JaCoCo version in his cache.
>>>
>>> 2) Cache a newer version on my Apache website and tweak the script
>>> accordingly.
>> Either one of those seems fine to me.
>>
>> If you fetch the newest version of the JaCoCo jars and put them on
>> your Apache site,
> I have copied the latest 0.7.9 artifacts to the
> public_html/derby/jacoco-jars directory of my apache account by
> sftping to minotaur.apache.org. But the artifacts are not visible at
> people.apache.org/~rhillegas and the directory tree there differs from
> the one on minotaur. I'm confused. I thought that all the apache
> machines shared the same account space. I guess it's time for another
> lesson from infra. Stay tuned...
Ok, the new jars are now visible from people.apache.org. The two
machines no longer share an account space.
>> I'd be glad to fiddle the Jenkins configuration and see if it fixes
>> the problem.
>>
>> thanks,
>>
>> bryan
>>
>
Re: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/5/17 7:36 PM, Bryan Pendleton wrote:
>>> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
>>> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>> If I understand that script, our JaCoCo runs rely on an old JaCoCo version
>> cached on Kristian's Apache website. Here are some things we could do:
>>
>> 1) Ask Kristian to upgrade the JaCoCo version in his cache.
>>
>> 2) Cache a newer version on my Apache website and tweak the script
>> accordingly.
> Either one of those seems fine to me.
>
> If you fetch the newest version of the JaCoCo jars and put them on
> your Apache site,
I have copied the latest 0.7.9 artifacts to the
public_html/derby/jacoco-jars directory of my apache account by sftping
to minotaur.apache.org. But the artifacts are not visible at
people.apache.org/~rhillegas and the directory tree there differs from
the one on minotaur. I'm confused. I thought that all the apache
machines shared the same account space. I guess it's time for another
lesson from infra. Stay tuned...
> I'd be glad to fiddle the Jenkins configuration and see if it fixes the problem.
>
> thanks,
>
> bryan
>
Re: need help configuring Jenkins
Posted by Bryan Pendleton <bp...@gmail.com>.
>> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
>> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>
> If I understand that script, our JaCoCo runs rely on an old JaCoCo version
> cached on Kristian's Apache website. Here are some things we could do:
>
> 1) Ask Kristian to upgrade the JaCoCo version in his cache.
>
> 2) Cache a newer version on my Apache website and tweak the script
> accordingly.
Either one of those seems fine to me.
If you fetch the newest version of the JaCoCo jars and put them on
your Apache site,
I'd be glad to fiddle the Jenkins configuration and see if it fixes the problem.
thanks,
bryan
Re: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
Thanks for digging into this, Bryan. More inline...
On 11/5/17 10:46 AM, Bryan Pendleton wrote:
>> https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-JaCoCo/49/
> This build correctly used Java 9.
>
> But it did not run successfully.
>
> I filed https://issues.apache.org/jira/browse/DERBY-6976 to track
> this, with the following description:
>
> The output said things like:
>
> [java] Java Result: 134
> [junit] Exception in thread "main"
> java.lang.reflect.InvocationTargetException
> [junit] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> [junit] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit] at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> [junit] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:500)
> [junit] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:512)
> [junit] Caused by: java.lang.RuntimeException: Class
> java/util/UUID could not be instrumented.
>
> Here, I see that to support Java 9, we need JaCoCo 0.7.8:
> https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
>
> But it looks like the Jenkins job is using 0.7.6:
>
> ++ cat jacocoversion.txt
> + echo 'JaCoCo version: 0.7.6.201602180812'
> JaCoCo version: 0.7.6.201602180812
>
> Rick, this one you probably have to track as a separate issue in JIRA;
> I don't think I can control the JaCoCo version by just changing a
> Jenkins configuration. Below is what we do in our build, but obviously
> it didn't automatically move from 0.7.6 to 0.7.8:
>
> # The files here are supposed to be updated automatically twice a month.
> JACOCO_URL=http://people.apache.org/~kristwaa/derby/jacoco-jars
> #wget -q -O trunk/tools/java/jacocoagent.jar $JACOCO_URL/jacocoagent.jar
> #wget -q -O trunk/tools/java/jacocoant.jar $JACOCO_URL/jacocoant.jar
> #wget -q -O jacocoversion.txt $JACOCO_URL/jacocoversion.txt
> curl $JACOCO_URL/jacocoagent.jar > trunk/tools/java/jacocoagent.jar
> curl $JACOCO_URL/jacocoant.jar > trunk/tools/java/jacocoant.jar
> curl $JACOCO_URL/jacocoversion.txt > jacocoversion.txt
If I understand that script, our JaCoCo runs rely on an old JaCoCo
version cached on Kristian's Apache website. Here are some things we
could do:
1) Ask Kristian to upgrade the JaCoCo version in his cache.
2) Cache a newer version on my Apache website and tweak the script
accordingly.
3) Something else?
Thanks,
-Rick
>
> thanks,
>
> bryan
>
Re: need help configuring Jenkins
Posted by Bryan Pendleton <bp...@gmail.com>.
> https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-JaCoCo/49/
This build correctly used Java 9.
But it did not run successfully.
I filed https://issues.apache.org/jira/browse/DERBY-6976 to track
this, with the following description:
The output said things like:
[java] Java Result: 134
[junit] Exception in thread "main"
java.lang.reflect.InvocationTargetException
[junit] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junit] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.base/java.lang.reflect.Method.invoke(Method.java:564)
[junit] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:500)
[junit] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallPremain(InstrumentationImpl.java:512)
[junit] Caused by: java.lang.RuntimeException: Class
java/util/UUID could not be instrumented.
Here, I see that to support Java 9, we need JaCoCo 0.7.8:
https://groups.google.com/forum/#!msg/jacoco/Zf0Cwj13G2g/wpyrYAEECAAJ
But it looks like the Jenkins job is using 0.7.6:
++ cat jacocoversion.txt
+ echo 'JaCoCo version: 0.7.6.201602180812'
JaCoCo version: 0.7.6.201602180812
Rick, this one you probably have to track as a separate issue in JIRA;
I don't think I can control the JaCoCo version by just changing a
Jenkins configuration. Below is what we do in our build, but obviously
it didn't automatically move from 0.7.6 to 0.7.8:
# The files here are supposed to be updated automatically twice a month.
JACOCO_URL=http://people.apache.org/~kristwaa/derby/jacoco-jars
#wget -q -O trunk/tools/java/jacocoagent.jar $JACOCO_URL/jacocoagent.jar
#wget -q -O trunk/tools/java/jacocoant.jar $JACOCO_URL/jacocoant.jar
#wget -q -O jacocoversion.txt $JACOCO_URL/jacocoversion.txt
curl $JACOCO_URL/jacocoagent.jar > trunk/tools/java/jacocoagent.jar
curl $JACOCO_URL/jacocoant.jar > trunk/tools/java/jacocoant.jar
curl $JACOCO_URL/jacocoversion.txt > jacocoversion.txt
thanks,
bryan
Re: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/5/17 9:08 AM, Bryan Pendleton wrote:
> The Derby-Trunk build seemed to work OK (Rick can you verify?) so I
> made the corresponding change to the Derby-trunk-suites.All and
> Derby-trunk-JaCoCo jobs and submitted them, too:
>
> https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-suites.All/130/
>
> https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-JaCoCo/49/
Thanks.
>
> Rick, how many jobs do you think we have that run against the trunk?
> Just those three? If you see any more, please let me know.
Derby-JaCoCo also runs against trunk. I don't know why we have a
Derby-JaCoCo and a Derby-trunk-JaCoCo. Maybe we can sort out that
redundancy after we figure out what to do about the JaCoCo version used
by the trunk JaCoCo.
I also set up a build job for 10.14--I hope I did it right.
Thanks,
-Rick
>
> thanks,
>
> bryan
>
Re: need help configuring Jenkins
Posted by Bryan Pendleton <bp...@gmail.com>.
The Derby-Trunk build seemed to work OK (Rick can you verify?) so I
made the corresponding change to the Derby-trunk-suites.All and
Derby-trunk-JaCoCo jobs and submitted them, too:
https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-suites.All/130/
https://builds.apache.org/view/A-D/view/Derby/job/Derby-trunk-JaCoCo/49/
Rick, how many jobs do you think we have that run against the trunk?
Just those three? If you see any more, please let me know.
thanks,
bryan
Re: need help configuring Jenkins
Posted by Rick Hillegas <ri...@gmail.com>.
On 11/5/17 8:38 AM, Bryan Pendleton wrote:
> Hi Rick,
>
> I found a drop list in the "configure" screen under "General" where I
> could pick a JDK, and I picked "JDK 1.9 latest".
Great. I was looking on the Build and Build Environment tabs.
Thanks,
-Rick
>
> I ran another build: https://builds.apache.org/job/Derby-trunk/2513/
>
> Let's keep an eye on this build and see how it behaves.
>
> thanks,
>
> bryan
> .
>
Re: need help configuring Jenkins
Posted by Bryan Pendleton <bp...@gmail.com>.
Hi Rick,
I found a drop list in the "configure" screen under "General" where I
could pick a JDK, and I picked "JDK 1.9 latest".
I ran another build: https://builds.apache.org/job/Derby-trunk/2513/
Let's keep an eye on this build and see how it behaves.
thanks,
bryan