From tim.bell at oracle.com Thu Jun 1 03:59:11 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 31 May 2017 20:59:11 -0700 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <0490bede-dde1-202c-017e-54eb38e9669f@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <0490bede-dde1-202c-017e-54eb38e9669f@oracle.com> Message-ID: <592F910F.6090501@oracle.com> Jon, Erik - > http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/trees.py.html One additional fix to correct a typo before pushing: line 868: @command('tdefapth') should be: @command('tdefpath') Tim On 05/31/17 08:13, Jonathan Gibbons wrote: > Magnus, > > Will push this later today. > > -- Jon > > > On 5/31/17 1:36 AM, Magnus Ihse Bursie wrote: >> On 2017-05-31 10:20, Erik Joelsson wrote: >>> Hello, >>> >>> Thanks for looking at this! >>> >>> I have renamed run_command to command_cmd. I agree the naming should >>> be consistent. >>> >>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >> >> Looks good to me. >> >> Jon, can you push Erik's patch? >> >> /Magnus >> >>> >>> /Erik >>> >>> >>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>> Looks good to me. Thanks for fixing this! >>>> >>>> A minor nit: >>>> >>>> +# This function cannot be named "command" since it clashes with the >>>> @command >>>> +# decorator. >>>> + at command('tcommand|tcmd') >>>> +def run_command(ui, repo, cmd, *args, **opts): >>>> >>>> +# This function cannot be named list since it clashes with the >>>> python builtin >>>> + at command('tlist') >>>> +def list_cmd(ui, repo, **opts): >>>> >>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>> command_cmd? But I'm ok if you want to keep the run_command name as >>>> well. >>>> >>>> /Magnus >>>> >>>> >>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>> over time. The technique used in trees has been deprecated for a >>>>> while and in 3.8, it no longer works. >>>>> >>>>> I have a patch that adopts the new method using decorators, >>>>> introduced in Mercurial 1.9. It also contains a fallback workaround >>>>> that keeps compatibility with older versions. >>>>> >>>>> For trees, there are further complications for versions between 1.9 >>>>> and 3.1 which the patch also handles. I have run the automatic >>>>> tests for all versions from 1.1 to latest as well as manually using >>>>> it with various versions. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>> >>>>> /Erik >>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Thu Jun 1 09:15:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 1 Jun 2017 11:15:45 +0200 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <592F910F.6090501@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <0490bede-dde1-202c-017e-54eb38e9669f@oracle.com> <592F910F.6090501@oracle.com> Message-ID: <04e2dcc9-1774-dbe8-e0c6-c6dec6f69f7f@oracle.com> ouch, good catch! Here is an updated webrev: http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.03/ /Erik On 2017-06-01 05:59, Tim Bell wrote: > Jon, Erik - > >> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/trees.py.html >> > > One additional fix to correct a typo before pushing: > > line 868: > @command('tdefapth') > > should be: > @command('tdefpath') > > Tim > > On 05/31/17 08:13, Jonathan Gibbons wrote: >> Magnus, >> >> Will push this later today. >> >> -- Jon >> >> >> On 5/31/17 1:36 AM, Magnus Ihse Bursie wrote: >>> On 2017-05-31 10:20, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Thanks for looking at this! >>>> >>>> I have renamed run_command to command_cmd. I agree the naming should >>>> be consistent. >>>> >>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >>> >>> Looks good to me. >>> >>> Jon, can you push Erik's patch? >>> >>> /Magnus >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>>> Looks good to me. Thanks for fixing this! >>>>> >>>>> A minor nit: >>>>> >>>>> +# This function cannot be named "command" since it clashes with the >>>>> @command >>>>> +# decorator. >>>>> + at command('tcommand|tcmd') >>>>> +def run_command(ui, repo, cmd, *args, **opts): >>>>> >>>>> +# This function cannot be named list since it clashes with the >>>>> python builtin >>>>> + at command('tlist') >>>>> +def list_cmd(ui, repo, **opts): >>>>> >>>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>>> command_cmd? But I'm ok if you want to keep the run_command name as >>>>> well. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>>> over time. The technique used in trees has been deprecated for a >>>>>> while and in 3.8, it no longer works. >>>>>> >>>>>> I have a patch that adopts the new method using decorators, >>>>>> introduced in Mercurial 1.9. It also contains a fallback workaround >>>>>> that keeps compatibility with older versions. >>>>>> >>>>>> For trees, there are further complications for versions between 1.9 >>>>>> and 3.1 which the patch also handles. I have run the automatic >>>>>> tests for all versions from 1.1 to latest as well as manually using >>>>>> it with various versions. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>> >>>> >>> >> > From sadhak001 at gmail.com Fri Jun 2 16:30:38 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 02 Jun 2017 16:30:38 +0000 Subject: SigTest - latest version failing In-Reply-To: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> References: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> Message-ID: Hi Kevin, Thanks for the response - you suggestion has brought our build back to green - see https://adopt-openjdk.ci.cloudbees.com/job/sigtest/306/console Cheers Mani On Wed, 31 May 2017 at 18:51 Kevin Looney wrote: > Hi Mani, > > The correct answer (for right now) is that cloudbees should stop > producing the maven plugins portion of SigTest. We are noticing object > incompatibilities between SigTest (built with JDK9) and Maven plugins > (built with JDK < 9). Once OpenJDK 9 is released (and Maven stabilizes on > JDK 9) we can revisit rebuilding SigTest with Maven plugin. > > This is a simple fix on the build to stop building SigTest Maven plugins: > > The cloudbees build needs to remove the ?mvn2.exe? property from the build > file: > > + ant build -Djdk5.home=/opt/jdk/jdk1.5.latest -Djdk7.home=/opt/jdk/jdk1.7.latest -Djdk8.home=/opt/jdk/jdk8.latest -Djdk9.home=/scratch/jenkins/workspace/sigtest/jdk-9 -Dmvn2.exe=/opt/maven/latest/bin/mvn > Buildfile: /scratch/jenkins/workspace/sigtest/build/build.xml > > This will complete the rest of the build product without issue. > > Thanks Mani, and let us know if you have any questions. > > Regards, > Kevin > > > > > > On 5/31/17 9:04 AM, Kevin Looney wrote: > > Hi Mani, > > Don't have an answer yet, but will soon. > > We are looking at the issue, but we are a bit short-staffed at the > moment. > > Thanks, > Kevin > > On 5/30/17 1:58 AM, Mani Sarkar wrote: > > Hi all, > > I have recently seen SigTest failing on our Cloudbees CI server, see > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/296/console. > > Anyone seen something similar, this version of SigTest needs JDK9 in > addition to the previous releases, so I have linked it to latest EA of JDK9 > when building - any comments on this? > > Any ideas, why it is failing? I see the maven-plug is failing: > sigtest-plugin. > > Cheers, > Mani > -- > > @theNeomatrix369 > * | **Blog > ** > | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > > *| **Bitbucket > * > * | **Github > ** | **LinkedIn > > * > *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will come > chasing after you!/* > -- > @theNeomatrix369 > *| **Blog > **| > *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > > *| **Bitbucket > * > * | **Github > ** | **LinkedIn > > * > *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will come > chasing after you!/* > > > > > > -- kevin.looney at oracle.com > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From jonathan.gibbons at oracle.com Sat Jun 3 01:23:25 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 02 Jun 2017 18:23:25 -0700 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> Message-ID: <59320F8D.3010700@oracle.com> Pushed. -- Jon On 05/31/2017 01:36 AM, Magnus Ihse Bursie wrote: > On 2017-05-31 10:20, Erik Joelsson wrote: >> Hello, >> >> Thanks for looking at this! >> >> I have renamed run_command to command_cmd. I agree the naming should >> be consistent. >> >> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ > > Looks good to me. > > Jon, can you push Erik's patch? > > /Magnus > >> >> /Erik >> >> >> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>> Looks good to me. Thanks for fixing this! >>> >>> A minor nit: >>> >>> +# This function cannot be named "command" since it clashes with the >>> @command >>> +# decorator. >>> + at command('tcommand|tcmd') >>> +def run_command(ui, repo, cmd, *args, **opts): >>> >>> +# This function cannot be named list since it clashes with the >>> python builtin >>> + at command('tlist') >>> +def list_cmd(ui, repo, **opts): >>> >>> Maybe use a more consistent naming scheme? E.g. rename the first >>> command_cmd? But I'm ok if you want to keep the run_command name as >>> well. >>> >>> /Magnus >>> >>> >>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>> The way a Mercurial plugin interacts with Mercurial has changed >>>> over time. The technique used in trees has been deprecated for a >>>> while and in 3.8, it no longer works. >>>> >>>> I have a patch that adopts the new method using decorators, >>>> introduced in Mercurial 1.9. It also contains a fallback workaround >>>> that keeps compatibility with older versions. >>>> >>>> For trees, there are further complications for versions between 1.9 >>>> and 3.1 which the patch also handles. I have run the automatic >>>> tests for all versions from 1.1 to latest as well as manually using >>>> it with various versions. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>> >>>> Webrev: http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>> >>>> /Erik >>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Sun Jun 4 21:11:55 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 4 Jun 2017 14:11:55 -0700 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <04e2dcc9-1774-dbe8-e0c6-c6dec6f69f7f@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <0490bede-dde1-202c-017e-54eb38e9669f@oracle.com> <592F910F.6090501@oracle.com> <04e2dcc9-1774-dbe8-e0c6-c6dec6f69f7f@oracle.com> Message-ID: <09db7796-810f-0667-0502-07e5f4930e1d@oracle.com> OK, I'll make sure everything is updated tomorrow. (i.e. Monday) -- Jon On 6/1/17 2:15 AM, Erik Joelsson wrote: > ouch, good catch! > > Here is an updated webrev: > > http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.03/ > > /Erik > > > On 2017-06-01 05:59, Tim Bell wrote: >> Jon, Erik - >> >>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/trees.py.html >>> >> >> One additional fix to correct a typo before pushing: >> >> line 868: >> @command('tdefapth') >> >> should be: >> @command('tdefpath') >> >> Tim >> >> On 05/31/17 08:13, Jonathan Gibbons wrote: >>> Magnus, >>> >>> Will push this later today. >>> >>> -- Jon >>> >>> >>> On 5/31/17 1:36 AM, Magnus Ihse Bursie wrote: >>>> On 2017-05-31 10:20, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> I have renamed run_command to command_cmd. I agree the naming should >>>>> be consistent. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >>>> >>>> Looks good to me. >>>> >>>> Jon, can you push Erik's patch? >>>> >>>> /Magnus >>>> >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>>>> Looks good to me. Thanks for fixing this! >>>>>> >>>>>> A minor nit: >>>>>> >>>>>> +# This function cannot be named "command" since it clashes with the >>>>>> @command >>>>>> +# decorator. >>>>>> + at command('tcommand|tcmd') >>>>>> +def run_command(ui, repo, cmd, *args, **opts): >>>>>> >>>>>> +# This function cannot be named list since it clashes with the >>>>>> python builtin >>>>>> + at command('tlist') >>>>>> +def list_cmd(ui, repo, **opts): >>>>>> >>>>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>>>> command_cmd? But I'm ok if you want to keep the run_command name as >>>>>> well. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>>>> over time. The technique used in trees has been deprecated for a >>>>>>> while and in 3.8, it no longer works. >>>>>>> >>>>>>> I have a patch that adopts the new method using decorators, >>>>>>> introduced in Mercurial 1.9. It also contains a fallback workaround >>>>>>> that keeps compatibility with older versions. >>>>>>> >>>>>>> For trees, there are further complications for versions between 1.9 >>>>>>> and 3.1 which the patch also handles. I have run the automatic >>>>>>> tests for all versions from 1.1 to latest as well as manually using >>>>>>> it with various versions. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Thu Jun 8 12:04:14 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 8 Jun 2017 14:04:14 +0200 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <59320F8D.3010700@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <59320F8D.3010700@oracle.com> Message-ID: On 2017-06-03 03:23, Jonathan Gibbons wrote: > Pushed. Thank you! :-) /Magnus > > -- Jon > > On 05/31/2017 01:36 AM, Magnus Ihse Bursie wrote: >> On 2017-05-31 10:20, Erik Joelsson wrote: >>> Hello, >>> >>> Thanks for looking at this! >>> >>> I have renamed run_command to command_cmd. I agree the naming should >>> be consistent. >>> >>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >> >> Looks good to me. >> >> Jon, can you push Erik's patch? >> >> /Magnus >> >>> >>> /Erik >>> >>> >>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>> Looks good to me. Thanks for fixing this! >>>> >>>> A minor nit: >>>> >>>> +# This function cannot be named "command" since it clashes with >>>> the @command >>>> +# decorator. >>>> + at command('tcommand|tcmd') >>>> +def run_command(ui, repo, cmd, *args, **opts): >>>> >>>> +# This function cannot be named list since it clashes with the >>>> python builtin >>>> + at command('tlist') >>>> +def list_cmd(ui, repo, **opts): >>>> >>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>> command_cmd? But I'm ok if you want to keep the run_command name as >>>> well. >>>> >>>> /Magnus >>>> >>>> >>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>> over time. The technique used in trees has been deprecated for a >>>>> while and in 3.8, it no longer works. >>>>> >>>>> I have a patch that adopts the new method using decorators, >>>>> introduced in Mercurial 1.9. It also contains a fallback >>>>> workaround that keeps compatibility with older versions. >>>>> >>>>> For trees, there are further complications for versions between >>>>> 1.9 and 3.1 which the patch also handles. I have run the automatic >>>>> tests for all versions from 1.1 to latest as well as manually >>>>> using it with various versions. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>> >>>>> /Erik >>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Thu Jun 8 18:02:41 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Jun 2017 11:02:41 -0700 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <59320F8D.3010700@oracle.com> Message-ID: <59399141.9020707@oracle.com> Note to self ... I still have to apply the fix for the typo that Tim noticed. I'll do that now. -- Jon On 06/08/2017 05:04 AM, Magnus Ihse Bursie wrote: > > On 2017-06-03 03:23, Jonathan Gibbons wrote: >> Pushed. > > Thank you! :-) > > /Magnus > >> >> -- Jon >> >> On 05/31/2017 01:36 AM, Magnus Ihse Bursie wrote: >>> On 2017-05-31 10:20, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Thanks for looking at this! >>>> >>>> I have renamed run_command to command_cmd. I agree the naming >>>> should be consistent. >>>> >>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >>> >>> Looks good to me. >>> >>> Jon, can you push Erik's patch? >>> >>> /Magnus >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>>> Looks good to me. Thanks for fixing this! >>>>> >>>>> A minor nit: >>>>> >>>>> +# This function cannot be named "command" since it clashes with >>>>> the @command >>>>> +# decorator. >>>>> + at command('tcommand|tcmd') >>>>> +def run_command(ui, repo, cmd, *args, **opts): >>>>> >>>>> +# This function cannot be named list since it clashes with the >>>>> python builtin >>>>> + at command('tlist') >>>>> +def list_cmd(ui, repo, **opts): >>>>> >>>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>>> command_cmd? But I'm ok if you want to keep the run_command name >>>>> as well. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>>> over time. The technique used in trees has been deprecated for a >>>>>> while and in 3.8, it no longer works. >>>>>> >>>>>> I have a patch that adopts the new method using decorators, >>>>>> introduced in Mercurial 1.9. It also contains a fallback >>>>>> workaround that keeps compatibility with older versions. >>>>>> >>>>>> For trees, there are further complications for versions between >>>>>> 1.9 and 3.1 which the patch also handles. I have run the >>>>>> automatic tests for all versions from 1.1 to latest as well as >>>>>> manually using it with various versions. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Thu Jun 8 20:32:35 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Jun 2017 13:32:35 -0700 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <59399141.9020707@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <59320F8D.3010700@oracle.com> <59399141.9020707@oracle.com> Message-ID: <5939B463.5080509@oracle.com> Fixed. -- Jon On 06/08/2017 11:02 AM, Jonathan Gibbons wrote: > > Note to self ... I still have to apply the fix for the typo that Tim > noticed. I'll do that now. > > -- Jon > > > On 06/08/2017 05:04 AM, Magnus Ihse Bursie wrote: >> >> On 2017-06-03 03:23, Jonathan Gibbons wrote: >>> Pushed. >> >> Thank you! :-) >> >> /Magnus >> >>> >>> -- Jon >>> >>> On 05/31/2017 01:36 AM, Magnus Ihse Bursie wrote: >>>> On 2017-05-31 10:20, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Thanks for looking at this! >>>>> >>>>> I have renamed run_command to command_cmd. I agree the naming >>>>> should be consistent. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >>>> >>>> Looks good to me. >>>> >>>> Jon, can you push Erik's patch? >>>> >>>> /Magnus >>>> >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>>>> Looks good to me. Thanks for fixing this! >>>>>> >>>>>> A minor nit: >>>>>> >>>>>> +# This function cannot be named "command" since it clashes with >>>>>> the @command >>>>>> +# decorator. >>>>>> + at command('tcommand|tcmd') >>>>>> +def run_command(ui, repo, cmd, *args, **opts): >>>>>> >>>>>> +# This function cannot be named list since it clashes with the >>>>>> python builtin >>>>>> + at command('tlist') >>>>>> +def list_cmd(ui, repo, **opts): >>>>>> >>>>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>>>> command_cmd? But I'm ok if you want to keep the run_command name >>>>>> as well. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>>>> over time. The technique used in trees has been deprecated for a >>>>>>> while and in 3.8, it no longer works. >>>>>>> >>>>>>> I have a patch that adopts the new method using decorators, >>>>>>> introduced in Mercurial 1.9. It also contains a fallback >>>>>>> workaround that keeps compatibility with older versions. >>>>>>> >>>>>>> For trees, there are further complications for versions between >>>>>>> 1.9 and 3.1 which the patch also handles. I have run the >>>>>>> automatic tests for all versions from 1.1 to latest as well as >>>>>>> manually using it with various versions. >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>>>> >>>>>>> /Erik >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From sadhak001 at gmail.com Fri Jun 9 16:14:52 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 09 Jun 2017 16:14:52 +0000 Subject: SigTest - latest version failing In-Reply-To: References: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> Message-ID: Hi All, Kevin, I recently had another failed build with SigTest but found out after some checking that building SigTest with JDK 9 EA build 170 builds successfully but builds after 170 break - something to check on your end as well. I have pinned the build to 170 now. Thanks, Cheers, Mani On Fri, 2 Jun 2017 at 17:30 Mani Sarkar wrote: > Hi Kevin, > > Thanks for the response - you suggestion has brought our build back to > green - see https://adopt-openjdk.ci.cloudbees.com/job/sigtest/306/console > > Cheers > Mani > > On Wed, 31 May 2017 at 18:51 Kevin Looney wrote: > >> Hi Mani, >> >> The correct answer (for right now) is that cloudbees should stop >> producing the maven plugins portion of SigTest. We are noticing object >> incompatibilities between SigTest (built with JDK9) and Maven plugins >> (built with JDK < 9). Once OpenJDK 9 is released (and Maven stabilizes on >> JDK 9) we can revisit rebuilding SigTest with Maven plugin. >> >> This is a simple fix on the build to stop building SigTest Maven plugins: >> >> The cloudbees build needs to remove the ?mvn2.exe? property from the >> build file: >> >> + ant build -Djdk5.home=/opt/jdk/jdk1.5.latest -Djdk7.home=/opt/jdk/jdk1.7.latest -Djdk8.home=/opt/jdk/jdk8.latest -Djdk9.home=/scratch/jenkins/workspace/sigtest/jdk-9 -Dmvn2.exe=/opt/maven/latest/bin/mvn >> Buildfile: /scratch/jenkins/workspace/sigtest/build/build.xml >> >> This will complete the rest of the build product without issue. >> >> Thanks Mani, and let us know if you have any questions. >> >> Regards, >> Kevin >> >> >> >> >> >> On 5/31/17 9:04 AM, Kevin Looney wrote: >> >> Hi Mani, >> >> Don't have an answer yet, but will soon. >> >> We are looking at the issue, but we are a bit short-staffed at the >> moment. >> >> Thanks, >> Kevin >> >> On 5/30/17 1:58 AM, Mani Sarkar wrote: >> >> Hi all, >> >> I have recently seen SigTest failing on our Cloudbees CI server, see >> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/296/console. >> >> Anyone seen something similar, this version of SigTest needs JDK9 in >> addition to the previous releases, so I have linked it to latest EA of JDK9 >> when building - any comments on this? >> >> Any ideas, why it is failing? I see the maven-plug is failing: >> sigtest-plugin. >> >> Cheers, >> Mani >> -- >> >> @theNeomatrix369 >> * | **Blog >> ** >> | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project - *MutabilityDetector >> >> *| **Bitbucket >> * >> * | **Github >> ** | **LinkedIn >> >> * >> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >> >> */Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!/* >> -- >> @theNeomatrix369 >> *| **Blog >> **| >> *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project - *MutabilityDetector >> >> *| **Bitbucket >> * >> * | **Github >> ** | **LinkedIn >> >> * >> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >> >> */Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!/* >> >> >> >> >> >> -- kevin.looney at oracle.com >> >> -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From kevin.looney at oracle.com Fri Jun 9 16:17:23 2017 From: kevin.looney at oracle.com (Kevin Looney) Date: Fri, 9 Jun 2017 09:17:23 -0700 Subject: SigTest - latest version failing In-Reply-To: References: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> Message-ID: <56a0c4f5-b9af-0b4e-21b6-f768a237ed5a@oracle.com> Thanks for the heads-up Mani! Kevin On 6/9/17 9:14 AM, Mani Sarkar wrote: > Hi All, Kevin, > > I recently had another failed build with SigTest but found out after > some checking that building SigTest with JDK 9 EA build 170 builds > successfully but builds after 170 break - something to check on your > end as well. > > I have pinned the build to 170 now. > > Thanks, > > Cheers, > Mani > > > > On Fri, 2 Jun 2017 at 17:30 Mani Sarkar > wrote: > > Hi Kevin, > > Thanks for the response - you suggestion has brought our build > back to green - see > https://adopt-openjdk.ci.cloudbees.com/job/sigtest/306/console > > Cheers > Mani > > On Wed, 31 May 2017 at 18:51 Kevin Looney > wrote: > > Hi Mani, > > The correct answer (for right now) is that cloudbees > should stop producing the maven plugins portion of SigTest. > We are noticing object incompatibilities between SigTest > (built with JDK9) and Maven plugins (built with JDK < 9). > Once OpenJDK 9 is released (and Maven stabilizes on JDK 9) we > can revisit rebuilding SigTest with Maven plugin. > > This is a simple fix on the build to stop building SigTest > Maven plugins: > > The cloudbees build needs to remove the ?mvn2.exe? property > from the build file: > >> + ant build -Djdk5.home=/opt/jdk/jdk1.5.latest >> -Djdk7.home=/opt/jdk/jdk1.7.latest >> -Djdk8.home=/opt/jdk/jdk8.latest >> -Djdk9.home=/scratch/jenkins/workspace/sigtest/jdk-9 >> -Dmvn2.exe=/opt/maven/latest/bin/mvn Buildfile: >> /scratch/jenkins/workspace/sigtest/build/build.xml > > This will complete the rest of the build product without issue. > > Thanks Mani, and let us know if you have any questions. > > Regards, > Kevin > > > > > > On 5/31/17 9:04 AM, Kevin Looney wrote: >> Hi Mani, >> >> Don't have an answer yet, but will soon. >> >> We are looking at the issue, but we are a bit >> short-staffed at the moment. >> >> Thanks, >> Kevin >> >> On 5/30/17 1:58 AM, Mani Sarkar wrote: >>> Hi all, >>> >>> I have recently seen SigTest failing on our Cloudbees CI >>> server, see >>> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/296/console. >>> >>> Anyone seen something similar, this version of SigTest needs >>> JDK9 in addition to the previous releases, so I have linked >>> it to latest EA of JDK9 when building - any comments on this? >>> >>> Any ideas, why it is failing? I see the maven-plug is >>> failing: sigtest-plugin. >>> >>> Cheers, >>> Mani >>> -- >>> @theNeomatrix369 >>> * | **Blog >>> >>> ** | *LJC Associate & >>> LJC Advocate (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project - *MutabilityDetector >>> >>> *| **Bitbucket >>> >>> * * | **Github >>> >>> ** | **LinkedIn >>> >>> * >>> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >>> >>> */Don't chase success, rather aim for "Excellence", and >>> success will come chasing after you!/* >>> -- >>> @theNeomatrix369 >>> *| **Blog >>> >>> **| *LJC Associate & LJC >>> Advocate (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project - *MutabilityDetector >>> >>> *| **Bitbucket >>> >>> * * | **Github >>> >>> ** | **LinkedIn >>> >>> * >>> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >>> >>> */Don't chase success, rather aim for "Excellence", and >>> success will come chasing after you!/* >> >> > > > -- > kevin.looney at oracle.com > > -- > @theNeomatrix369 *| **Blog > **| *LJC Associate & LJC > Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > *| **Bitbucket > * * | **Github > ** | **LinkedIn > * > *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success > will come chasing after you!/* > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC > Advocate (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > *| **Bitbucket > * * | **Github > ** | **LinkedIn > * > *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* -- kevin.looney at oracle.com From sadhak001 at gmail.com Fri Jun 9 17:22:47 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 09 Jun 2017 17:22:47 +0000 Subject: SigTest - latest version failing In-Reply-To: <68446E27-AED7-4A0B-9C48-1940E53361C1@oracle.com> References: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> <56a0c4f5-b9af-0b4e-21b6-f768a237ed5a@oracle.com> <68446E27-AED7-4A0B-9C48-1940E53361C1@oracle.com> Message-ID: Ho Alexey, Good catch, its sorted now, the tar.gz is of the right size - feel free to give it a whirl. Thanks. Cheers, Mani On Fri, 9 Jun 2017 at 18:03 Alexey Fedorchenko < alexey.fedorchenko at oracle.com> wrote: > Hello! > > Please, take a look at the ?Last Successful Artifacts? for the Sigtest > job. > The current size (558.85 MB) looks very strange for the Sigtest results. > > For an example ?jdk-9-ea+170_linux-x64_bin.tar.gz? (293.2 MB) is included > in these artifacts. > > Thank you. > > > ?Alexey > > On Jun 9, 2017, at 9:17 AM, Kevin Looney wrote: > > Thanks for the heads-up Mani! > > Kevin > > On 6/9/17 9:14 AM, Mani Sarkar wrote: > > Hi All, Kevin, > > I recently had another failed build with SigTest but found out after some > checking that building SigTest with JDK 9 EA build 170 builds successfully > but builds after 170 break - something to check on your end as well. > > I have pinned the build to 170 now. > > Thanks, > > Cheers, > Mani > > > > On Fri, 2 Jun 2017 at 17:30 Mani Sarkar wrote: > >> Hi Kevin, >> >> Thanks for the response - you suggestion has brought our build back to >> green - see >> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/306/console >> >> Cheers >> Mani >> >> On Wed, 31 May 2017 at 18:51 Kevin Looney >> wrote: >> >>> Hi Mani, >>> >>> The correct answer (for right now) is that cloudbees should stop >>> producing the maven plugins portion of SigTest. We are noticing object >>> incompatibilities between SigTest (built with JDK9) and Maven plugins >>> (built with JDK < 9). Once OpenJDK 9 is released (and Maven stabilizes on >>> JDK 9) we can revisit rebuilding SigTest with Maven plugin. >>> >>> This is a simple fix on the build to stop building SigTest Maven plugins: >>> >>> The cloudbees build needs to remove the ?mvn2.exe? property from the >>> build file: >>> >>> + ant build -Djdk5.home=/opt/jdk/jdk1.5.latest -Djdk7.home=/opt/jdk/jdk1.7.latest -Djdk8.home=/opt/jdk/jdk8.latest -Djdk9.home=/scratch/jenkins/workspace/sigtest/jdk-9 -Dmvn2.exe=/opt/maven/latest/bin/mvn >>> Buildfile: /scratch/jenkins/workspace/sigtest/build/build.xml >>> >>> This will complete the rest of the build product without issue. >>> >>> Thanks Mani, and let us know if you have any questions. >>> >>> Regards, >>> Kevin >>> >>> >>> >>> >>> >>> On 5/31/17 9:04 AM, Kevin Looney wrote: >>> >>> Hi Mani, >>> >>> Don't have an answer yet, but will soon. >>> >>> We are looking at the issue, but we are a bit short-staffed at the >>> moment. >>> >>> Thanks, >>> Kevin >>> >>> On 5/30/17 1:58 AM, Mani Sarkar wrote: >>> >>> Hi all, >>> >>> I have recently seen SigTest failing on our Cloudbees CI server, see >>> https://adopt-openjdk.ci.cloudbees.com/job/sigtest/296/console. >>> >>> Anyone seen something similar, this version of SigTest needs JDK9 in >>> addition to the previous releases, so I have linked it to latest EA of JDK9 >>> when building - any comments on this? >>> >>> Any ideas, why it is failing? I see the maven-plug is failing: >>> sigtest-plugin. >>> >>> Cheers, >>> Mani >>> -- >>> >>> @theNeomatrix369 >>> * | **Blog >>> >>> ** | *LJC Associate & LJC Advocate >>> (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project - *MutabilityDetector >>> >>> *| **Bitbucket >>> >>> * * | **Github >>> ** | >>> **LinkedIn >>> * >>> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >>> >>> */Don't chase success, rather aim for "Excellence", and success will >>> come chasing after you!/* >>> -- >>> @theNeomatrix369 >>> *| **Blog >>> >>> **| *LJC Associate & LJC Advocate >>> (@adoptopenjdk & @adoptajsr programs) >>> *Meet-a-Project - *MutabilityDetector >>> >>> *| **Bitbucket >>> >>> * * | **Github >>> ** | >>> **LinkedIn >>> * >>> *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ >>> >>> */Don't chase success, rather aim for "Excellence", and success will >>> come chasing after you!/* >>> >>> >>> >>> >>> >>> -- kevin.looney at oracle.com >>> >>> -- >> @theNeomatrix369 * | **Blog >> ** | *LJC Associate & LJC Advocate >> (@adoptopenjdk & @adoptajsr programs) >> *Meet-a-Project - *MutabilityDetector >> * | **Bitbucket >> * * | **Github >> * * | **LinkedIn >> * >> *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ >> >> *Don't chase success, rather aim for "Excellence", and success will come >> chasing after you!* >> > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > > > -- kevin.looney at oracle.com > > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2018:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From erik.joelsson at oracle.com Thu Jun 22 06:03:39 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 22 Jun 2017 08:03:39 +0200 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <5939B463.5080509@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> <59320F8D.3010700@oracle.com> <59399141.9020707@oracle.com> <5939B463.5080509@oracle.com> Message-ID: <3a171ebe-0ed1-6029-b600-39a6d8596822@oracle.com> Thank you Jon for handling this! (and sorry for the late reply, I tend to miss checking this list) /Erik On 2017-06-08 22:32, Jonathan Gibbons wrote: > Fixed. > > -- Jon > > On 06/08/2017 11:02 AM, Jonathan Gibbons wrote: >> >> Note to self ... I still have to apply the fix for the typo that Tim >> noticed. I'll do that now. >> >> -- Jon >> >> >> On 06/08/2017 05:04 AM, Magnus Ihse Bursie wrote: >>> >>> On 2017-06-03 03:23, Jonathan Gibbons wrote: >>>> Pushed. >>> >>> Thank you! :-) >>> >>> /Magnus >>> >>>> >>>> -- Jon >>>> >>>> On 05/31/2017 01:36 AM, Magnus Ihse Bursie wrote: >>>>> On 2017-05-31 10:20, Erik Joelsson wrote: >>>>>> Hello, >>>>>> >>>>>> Thanks for looking at this! >>>>>> >>>>>> I have renamed run_command to command_cmd. I agree the naming >>>>>> should be consistent. >>>>>> >>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.02/ >>>>> >>>>> Looks good to me. >>>>> >>>>> Jon, can you push Erik's patch? >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2017-05-17 12:30, Magnus Ihse Bursie wrote: >>>>>>> Looks good to me. Thanks for fixing this! >>>>>>> >>>>>>> A minor nit: >>>>>>> >>>>>>> +# This function cannot be named "command" since it clashes with >>>>>>> the @command >>>>>>> +# decorator. >>>>>>> + at command('tcommand|tcmd') >>>>>>> +def run_command(ui, repo, cmd, *args, **opts): >>>>>>> >>>>>>> +# This function cannot be named list since it clashes with the >>>>>>> python builtin >>>>>>> + at command('tlist') >>>>>>> +def list_cmd(ui, repo, **opts): >>>>>>> >>>>>>> Maybe use a more consistent naming scheme? E.g. rename the first >>>>>>> command_cmd? But I'm ok if you want to keep the run_command name >>>>>>> as well. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> On 2017-04-18 19:35, Erik Joelsson wrote: >>>>>>>> The way a Mercurial plugin interacts with Mercurial has changed >>>>>>>> over time. The technique used in trees has been deprecated for >>>>>>>> a while and in 3.8, it no longer works. >>>>>>>> >>>>>>>> I have a patch that adopts the new method using decorators, >>>>>>>> introduced in Mercurial 1.9. It also contains a fallback >>>>>>>> workaround that keeps compatibility with older versions. >>>>>>>> >>>>>>>> For trees, there are further complications for versions between >>>>>>>> 1.9 and 3.1 which the patch also handles. I have run the >>>>>>>> automatic tests for all versions from 1.1 to latest as well as >>>>>>>> manually using it with various versions. >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901672 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~erikj/CODETOOLS-7901672/webrev.01/ >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >