From magnus.ihse.bursie at oracle.com Wed May 17 10:24:42 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 May 2017 12:24:42 +0200 Subject: RFR: CODETOOLS-7901950: jcheck does not work with Mercurial 4.1 In-Reply-To: References: Message-ID: Looks good to me. Can someone with write access please push these changes? /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 jcheck and defpath has been deprecated for > a while and in 4.1, 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. > > Bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7901950 > > Webrev: > http://cr.openjdk.java.net/~erikj/CODETOOLS-7901950/jcheck-webrev.01/ > > > I have the same changes ready for defpath which doesn't have it's own > component in Jira. > > Webrev: > http://cr.openjdk.java.net/~erikj/CODETOOLS-7901950/defpath-webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Wed May 17 10:30:32 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 17 May 2017 12:30:32 +0200 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> Message-ID: 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 Tue May 30 08:58:12 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 30 May 2017 08:58:12 +0000 Subject: SigTest - latest version failing In-Reply-To: References: Message-ID: 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!* From erik.joelsson at oracle.com Wed May 31 08:20:58 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 31 May 2017 10:20:58 +0200 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> Message-ID: <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> 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/ /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 Wed May 31 08:36:28 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 31 May 2017 10:36:28 +0200 Subject: RFR: CODETOOLS-7901672: trees extension broken after upgrade to mercurial 3.8.1 In-Reply-To: <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> References: <21969d4c-b650-6903-213d-1297a3e85755@oracle.com> <7fd49688-5e71-d0ed-4c98-47d06e728e35@oracle.com> Message-ID: 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 dalibor.topic at oracle.com Wed May 31 09:29:45 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Wed, 31 May 2017 11:29:45 +0200 Subject: SigTest - latest version failing In-Reply-To: References: Message-ID: <74962d41-492c-0200-eae1-6e48f3ae23c1@oracle.com> On 30.05.2017 10:58, 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. " [exec] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch." It sounds like you'll need to take a look at the full stack trace. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From jonathan.gibbons at oracle.com Wed May 31 15:13:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 31 May 2017 08:13:13 -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: <0490bede-dde1-202c-017e-54eb38e9669f@oracle.com> 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 kevin.looney at oracle.com Wed May 31 16:04:23 2017 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 31 May 2017 09:04:23 -0700 Subject: SigTest - latest version failing In-Reply-To: References: Message-ID: 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 From kevin.looney at oracle.com Wed May 31 17:51:25 2017 From: kevin.looney at oracle.com (Kevin Looney) Date: Wed, 31 May 2017 10:51:25 -0700 Subject: SigTest - latest version failing In-Reply-To: References: Message-ID: <5d4956be-9c41-fc54-6cb7-b8c9071200ff@oracle.com> 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