From andrewluotechnologies at outlook.com Mon Jan 7 05:02:48 2019 From: andrewluotechnologies at outlook.com (Andrew Luo) Date: Mon, 7 Jan 2019 05:02:48 +0000 Subject: [PATCH] Enable jtreg tests to run on WSL (Windows Subsystem for Linux) In-Reply-To: References: Message-ID: Adding jtreg-dev. Didn't realize that there was such a mailing list until later (the jtreg code lives under code-tools repository) Thanks, -Andrew -----Original Message----- From: code-tools-dev On Behalf Of Andrew Luo Sent: Sunday, January 6, 2019 11:30 AM To: code-tools-dev at openjdk.java.net Subject: [PATCH] Enable jtreg tests to run on WSL (Windows Subsystem for Linux) We recently added support for building OpenJDK on WSL (targeting Windows; targeting Linux always worked). However, running tests on WSL did not work, and we determined that some changes would be needed to jtreg to support this use case. In particular, jtreg needs to know if it is running on WSL targeting Windows or WSL targeting Linux (when targeting Linux, no changes are needed as it is the same as any other Linux system, but when targeting Windows jtreg needs to run shell scripts in a special manner - in particular, calling "wsl.exe sh" instead of just "sh" since it's a Windows boot JDK, as well as translating environment variables using WSLENV...) I've attached my patch with my proposed changes. I welcome any thoughts/feedback. (See https://bugs.openjdk.java.net/browse/JDK-8215445 for more details about supporting WSL for building OpenJDK) Thanks, -Andrew -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From jonathan.gibbons at oracle.com Mon Jan 7 15:27:26 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 7 Jan 2019 07:27:26 -0800 Subject: [PATCH] Enable jtreg tests to run on WSL (Windows Subsystem for Linux) In-Reply-To: References: Message-ID: Andrew, I'll take a look at this in detail later today. -- Jon On 1/6/19 9:02 PM, Andrew Luo wrote: > Adding jtreg-dev. Didn't realize that there was such a mailing list until later (the jtreg code lives under code-tools repository) > > Thanks, > > -Andrew > > -----Original Message----- > From: code-tools-dev On Behalf Of Andrew Luo > Sent: Sunday, January 6, 2019 11:30 AM > To: code-tools-dev at openjdk.java.net > Subject: [PATCH] Enable jtreg tests to run on WSL (Windows Subsystem for Linux) > > We recently added support for building OpenJDK on WSL (targeting Windows; targeting Linux always worked). However, running tests on WSL did not work, and we determined that some changes would be needed to jtreg to support this use case. In particular, jtreg needs to know if it is running on WSL targeting Windows or WSL targeting Linux (when targeting Linux, no changes are needed as it is the same as any other Linux system, but when targeting Windows jtreg needs to run shell scripts in a special manner - in particular, calling "wsl.exe sh" instead of just "sh" since it's a Windows boot JDK, as well as translating environment variables using WSLENV...) > > I've attached my patch with my proposed changes. I welcome any thoughts/feedback. > > (See https://bugs.openjdk.java.net/browse/JDK-8215445 for more details about supporting WSL for building OpenJDK) > > Thanks, > > -Andrew From jonathan.gibbons at oracle.com Wed Jan 9 21:34:38 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 9 Jan 2019 13:34:38 -0800 Subject: [PATCH] Enable jtreg tests to run on WSL (Windows Subsystem for Linux) In-Reply-To: <4a0e038a-249a-b542-1731-93bca8c80555@oracle.com> References: <658a4caf-0400-e31b-d3b1-79e7f00a2c06@oracle.com> <71ed2368-0051-8243-ced9-27598d6c7368@oracle.com> <4a0e038a-249a-b542-1731-93bca8c80555@oracle.com> Message-ID: <237acedd-1eda-5c36-9c36-31d1f8aa8bc0@oracle.com> I have pushed a version of this patch to the jtreg repo. I did some renaming: I've simplified the command-line option to just `-wsl`, improved the command line help, and internally, used more verbose names like "useWindowsSubsystemForLinux" instead of the more cryptic "wslWindowsTarget". It may still be possible to refine the use of the option, so that it may not be necessary to specify the option if jtreg can determine whether to use Cygwin or WSL. But this can be done as a followup changeset. We'll do some additional testing of this feature before promoting a new version of jtreg for more widespread use. -- Jon On 01/08/2019 01:21 PM, Jonathan Gibbons wrote: > Andrew, > > One more enhancement, in webrev.03. The new command line option is > rejected if jtreg is not running on Windows. > > -- Jon > > > On 01/08/2019 10:30 AM, Andrew Luo wrote: >> >> Hi Jon, >> >> Thanks, looks good to me. >> >> I guess that a path is a subset of path list, although I?m not sure >> why Microsoft gives them separate suffixes? >> >> In Windows, technically the correct case is ?Path?.? However often >> times people use PATH (or path), and Linux environment variables are >> case sensitive, while Windows environment variables are not, so if >> someone set Linux PATH, path, and Path, we don?t want any of them to >> be translated to Windows, as I believe any of them would override the >> Windows path. >> >> I didn?t see any blank env elements, the .isEmpty() check must have >> been by habit. >> >> I did test your changes on my WSL environment and everything >> compiles/works. >> >> Thanks, >> >> -Andrew >> >> *From:*Jonathan Gibbons >> *Sent:* Monday, January 7, 2019 4:26 PM >> *To:* Andrew Luo ; >> code-tools-dev at openjdk.java.net >> *Subject:* Re: [PATCH] Enable jtreg tests to run on WSL (Windows >> Subsystem for Linux) >> >> Andrew, >> >> I've put out an updated webrev, that is somewhat simpler than your >> version, although it should be functionally equivalent. In >> particular, it has a much smaller impact on the non-WSL code. >> >> Some questions: >> >> ? * Why is it important to distinguish "path" and "path list"? Isn't a >> ??? "path" just a "path list" with a single entry? In other words, can >> ??? we always use suffix `/l` for a list of one-or-more paths? >> ? * Is it important to ignore case when checking for "PATH"? Would the >> ??? Windows environment ever contain an env variable "path"? >> ? * The env should never have entries in it with "blank" names; was it >> ??? just defensive programming on your part to check for blank names >> ??? and ignore them, or did you see them in practice? >> ? * I'm not set up here right now to be able to test with WSL; can you >> ??? try building and testing this version of jtreg? >> >> -- Jon >> >> Webrev: http://cr.openjdk.java.net/~jjg/7902357/webrev.02/ >> >> > From jonathan.gibbons at oracle.com Wed Jan 9 21:45:11 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Jan 2019 21:45:11 +0000 Subject: hg: code-tools/jtreg: 7902357: Support Windows Subsystem for Linux (WSL) Message-ID: <201901092145.x09LjBa4023783@aojmv0008.oracle.com> Changeset: 60fdece98830 Author: jjg Date: 2019-01-09 13:45 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/60fdece98830 7902357: Support Windows Subsystem for Linux (WSL) Contributed-by: andrewluotechnologies at outlook.com, jonathan.gibbons at oracle.com ! README ! src/share/classes/com/sun/javatest/regtest/Main.java ! src/share/classes/com/sun/javatest/regtest/config/RegressionParameters.java ! src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java ! src/share/classes/com/sun/javatest/regtest/tool/Tool.java ! src/share/classes/com/sun/javatest/regtest/tool/i18n.properties From jonathan.gibbons at oracle.com Fri Jan 11 18:31:33 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2019 18:31:33 +0000 Subject: hg: code-tools/jtreg: 2 new changesets Message-ID: <201901111831.x0BIVXwV018476@aojmv0008.oracle.com> Changeset: 12ce935485e1 Author: jjg Date: 2019-01-11 10:17 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/12ce935485e1 Fix over-simplification of ShellAction.getWSLPath ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java Changeset: 80abb3f13640 Author: jjg Date: 2019-01-11 10:31 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/80abb3f13640 fix oversimplification of getWSLPath ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java From jonathan.gibbons at oracle.com Wed Jan 16 19:13:54 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Jan 2019 19:13:54 +0000 Subject: hg: code-tools/jtreg: Set EXE_SUFFIX in WSL mode Message-ID: <201901161913.x0GJDsr4013603@aojmv0008.oracle.com> Changeset: 1ec40d0dd0b5 Author: jjg Date: 2019-01-16 11:13 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/1ec40d0dd0b5 Set EXE_SUFFIX in WSL mode ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java From jonathan.gibbons at oracle.com Wed Jan 16 21:32:45 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Jan 2019 21:32:45 +0000 Subject: hg: code-tools/jtreg: Update for WSL; remove trailing whitespace Message-ID: <201901162132.x0GLWjeV022135@aojmv0008.oracle.com> Changeset: ec2992ac85d0 Author: jjg Date: 2019-01-16 13:32 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/ec2992ac85d0 Update for WSL; remove trailing whitespace ! src/share/doc/javatest/regtest/faq.md ! src/share/doc/javatest/regtest/tag-spec.html From jonathan.gibbons at oracle.com Fri Jan 18 02:13:56 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 18 Jan 2019 02:13:56 +0000 Subject: hg: code-tools/jtreg: Set EXESUFFIX before WSLENV Message-ID: <201901180213.x0I2Du0x005097@aojmv0008.oracle.com> Changeset: e4bfad6eca4f Author: jjg Date: 2019-01-17 18:13 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/e4bfad6eca4f Set EXESUFFIX before WSLENV Contributed-by: andrewluotechnologies at outlook.com ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java From jonathan.gibbons at oracle.com Fri Jan 25 19:21:34 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 25 Jan 2019 19:21:34 +0000 Subject: hg: code-tools/jtreg: Add support for TEST.ROOT Message-ID: <201901251921.x0PJLYTa018942@aojmv0008.oracle.com> Changeset: 9d5ac9297316 Author: jjg Date: 2019-01-25 11:21 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/9d5ac9297316 Add support for TEST.ROOT ! src/share/classes/com/sun/javatest/regtest/exec/RegressionScript.java ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java ! src/share/doc/javatest/regtest/tag-spec.html ! test/rerun/std/AppletTest.agentvm.out ! test/rerun/std/AppletTest.othervm.out ! test/rerun/std/BuildTest.agentvm.out ! test/rerun/std/BuildTest.othervm.out ! test/rerun/std/CompileTest.agentvm.out ! test/rerun/std/CompileTest.othervm.out ! test/rerun/std/JUnitTest.agentvm.out ! test/rerun/std/JUnitTest.othervm.out ! test/rerun/std/MainTest.agentvm.out ! test/rerun/std/MainTest.othervm.out ! test/rerun/std/ShellTest.agentvm.out ! test/rerun/std/ShellTest.othervm.out ! test/rerun/std/TestNGTest.agentvm.out ! test/rerun/std/TestNGTest.othervm.out ! test/rerun/testng/TestNGTest.agentvm.out ! test/rerun/testng/TestNGTest.othervm.out From jonathan.gibbons at oracle.com Fri Jan 25 20:02:48 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 25 Jan 2019 20:02:48 +0000 Subject: hg: code-tools/jtreg: Set FS, PS, NULL for shell tests Message-ID: <201901252002.x0PK2m7T005501@aojmv0008.oracle.com> Changeset: b4ec8b1f32b4 Author: jjg Date: 2019-01-25 12:02 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/b4ec8b1f32b4 Set FS, PS, NULL for shell tests ! src/share/classes/com/sun/javatest/regtest/exec/ShellAction.java ! src/share/doc/javatest/regtest/tag-spec.html ! test/rerun/std/ShellTest.agentvm.out ! test/rerun/std/ShellTest.othervm.out From thomas.stuefe at gmail.com Tue Jan 29 14:06:33 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Jan 2019 15:06:33 +0100 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries Message-ID: Greetings, May I please have your opinions about the following fix: bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 cr: http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ jtreg tests containing references to external test libraries (e.g. @library /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and references to those test support classes will not be resolved and result in red wiggly lines in Intellij. This affects mostly jtreg tests for the hotspot, since those typically rely on /test/lib. This patch causes the Intellij jtreg plugin properly recognize and handle the external.lib.roots entry in the test suite configuration files. The TEST.ROOT file for an opened source is parsed and the external library path extracted. I am not sure whether this is the best way to go about it or whether this is too expensive though. The parsing is only done for the first file under a given TEST.ROOT, so it should be okay? The plugin works for me, on a quite underpowered ultrabook. Note that I also added a lot of logging, all debug level, to aid me in development. If necessary I can remove it but would prefer not to. Please note that I'm quite new to jtreg plugin development as well as to the jtreg internals, so I may miss something obvious. Would appreciate it if someone more knowledgeable reviews it (Maurizio?). Thanks & Best Regards, Thomas From maurizio.cimadamore at oracle.com Tue Jan 29 14:24:12 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 29 Jan 2019 14:24:12 +0000 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: References: Message-ID: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> Hi, this looks like a solid piece of work; thanks for adding all the documents, they make what's going on very explicit. Do you have a pointer to a test that rely on this feature? I'd like to give this patch a spin. Cheers Maurizio On 29/01/2019 14:06, Thomas St?fe wrote: > Greetings, > > May I please have your opinions about the following fix: > > bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ > > jtreg tests containing references to external test libraries (e.g. @library > /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and > references to those test support classes will not be resolved and result in > red wiggly lines in Intellij. This affects mostly jtreg tests for the > hotspot, since those typically rely on /test/lib. > > This patch causes the Intellij jtreg plugin properly recognize and handle > the external.lib.roots entry in the test suite configuration files. The > TEST.ROOT file for an opened source is parsed and the external library path > extracted. I am not sure whether this is the best way to go about it or > whether this is too expensive though. The parsing is only done for the > first file under a given TEST.ROOT, so it should be okay? > > The plugin works for me, on a quite underpowered ultrabook. Note that I > also added a lot of logging, all debug level, to aid me in development. If > necessary I can remove it but would prefer not to. > > Please note that I'm quite new to jtreg plugin development as well as to > the jtreg internals, so I may miss something obvious. Would appreciate it > if someone more knowledgeable reviews it (Maurizio?). > > Thanks & Best Regards, Thomas From thomas.stuefe at gmail.com Tue Jan 29 14:32:56 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Jan 2019 15:32:56 +0100 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> Message-ID: On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > Hi, > this looks like a solid piece of work; thanks for adding all the > documents, they make what's going on very explicit. > > Thanks! > Do you have a pointer to a test that rely on this feature? I'd like to > give this patch a spin. > For example, anything in hotspot/jtreg/runtime, e.g. runtime/ErrorHandling. Alternatively, you could grep for "import jdk.test.lib.process". There are some tests in the jdk too. Cheers, Thomas > > Cheers > Maurizio > > On 29/01/2019 14:06, Thomas St?fe wrote: > > Greetings, > > > > May I please have your opinions about the following fix: > > > > bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ > > > > jtreg tests containing references to external test libraries (e.g. > @library > > /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and > > references to those test support classes will not be resolved and result > in > > red wiggly lines in Intellij. This affects mostly jtreg tests for the > > hotspot, since those typically rely on /test/lib. > > > > This patch causes the Intellij jtreg plugin properly recognize and handle > > the external.lib.roots entry in the test suite configuration files. The > > TEST.ROOT file for an opened source is parsed and the external library > path > > extracted. I am not sure whether this is the best way to go about it or > > whether this is too expensive though. The parsing is only done for the > > first file under a given TEST.ROOT, so it should be okay? > > > > The plugin works for me, on a quite underpowered ultrabook. Note that I > > also added a lot of logging, all debug level, to aid me in development. > If > > necessary I can remove it but would prefer not to. > > > > Please note that I'm quite new to jtreg plugin development as well as to > > the jtreg internals, so I may miss something obvious. Would appreciate it > > if someone more knowledgeable reviews it (Maurizio?). > > > > Thanks & Best Regards, Thomas > From jonathan.gibbons at oracle.com Tue Jan 29 23:11:24 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 29 Jan 2019 23:11:24 +0000 Subject: hg: code-tools/jtreg: 7902372: Support building jtreg with recent versions of JDK. Message-ID: <201901292311.x0TNBOVA021133@aojmv0008.oracle.com> Changeset: 9c45ebdebe96 Author: jjg Date: 2019-01-29 15:11 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/9c45ebdebe96 7902372: Support building jtreg with recent versions of JDK. ! make/Defs.gmk From maurizio.cimadamore at oracle.com Wed Jan 30 16:27:49 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 30 Jan 2019 16:27:49 +0000 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> Message-ID: <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> The patch seems to be working correctly - I used it in my existing project and it seems to work fine. As for the review, you need to bump the jtreg plugin version, e.g. like this: --- a/plugins/idea/resources/META-INF/plugin.xml??????? Tue Jan 29 15:11:03 2019 -0800 +++ b/plugins/idea/resources/META-INF/plugin.xml??????? Wed Jan 30 16:27:18 2019 +0000 @@ -26,13 +26,13 @@ ? ???? jtreg ???? jtreg Test Support -??? 1.8 +??? 1.9 ???? jtreg framework. ???? ]]> ???? ???? Thanks Maurizio On 29/01/2019 14:32, Thomas St?fe wrote: > > On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore > > wrote: > > Hi, > this looks like a solid piece of work; thanks for adding all the > documents, they make what's going on very explicit. > > > Thanks! > > Do you have a pointer to a test that rely on this feature? I'd > like to > give this patch a spin. > > > For example, anything in hotspot/jtreg/runtime, e.g. > runtime/ErrorHandling. Alternatively, you could grep for "import > jdk.test.lib.process". There are some tests in the jdk too. > > Cheers, Thomas > > > Cheers > Maurizio > > On 29/01/2019 14:06, Thomas St?fe wrote: > > Greetings, > > > > May I please have your opinions about the following fix: > > > > bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ > > > > jtreg tests containing references to external test libraries > (e.g. @library > > /test/lib) are not properly handled(e.g. > jdk.test.lib.process.*), and > > references to those test support classes will not be resolved > and result in > > red wiggly lines in Intellij. This affects mostly jtreg tests > for the > > hotspot, since those typically rely on /test/lib. > > > > This patch causes the Intellij jtreg plugin properly recognize > and handle > > the external.lib.roots entry in the test suite configuration > files. The > > TEST.ROOT file for an opened source is parsed and the external > library path > > extracted. I am not sure whether this is the best way to go > about it or > > whether this is too expensive though. The parsing is only done > for the > > first file under a given TEST.ROOT, so it should be okay? > > > > The plugin works for me, on a quite underpowered ultrabook. Note > that I > > also added a lot of logging, all debug level, to aid me in > development. If > > necessary I can remove it but would prefer not to. > > > > Please note that I'm quite new to jtreg plugin development as > well as to > > the jtreg internals, so I may miss something obvious. Would > appreciate it > > if someone more knowledgeable reviews it (Maurizio?). > > > > Thanks & Best Regards, Thomas > From thomas.stuefe at gmail.com Wed Jan 30 17:24:32 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 Jan 2019 18:24:32 +0100 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> Message-ID: Thanks Maurizio. I'll prepare another webrev, but probably not before next week. Do I need a second reviewer for codetool patches? Cheers, Thomas On Wed, Jan 30, 2019 at 5:27 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > The patch seems to be working correctly - I used it in my existing project > and it seems to work fine. > > As for the review, you need to bump the jtreg plugin version, e.g. like > this: > > --- a/plugins/idea/resources/META-INF/plugin.xml Tue Jan 29 > 15:11:03 2019 -0800 > +++ b/plugins/idea/resources/META-INF/plugin.xml Wed Jan 30 > 16:27:18 2019 +0000 > @@ -26,13 +26,13 @@ > > jtreg > jtreg Test Support > - 1.8 > + 1.9 > Allows execution of tests developed using the "http://openjdk.java.net/jtreg/" >jtreg > framework. > ]]> > > - Add support for IntelliJ IDE2018.3 > + Allow support for external library resolution > ]]> > > > > Thanks > Maurizio > On 29/01/2019 14:32, Thomas St?fe wrote: > > > On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> Hi, >> this looks like a solid piece of work; thanks for adding all the >> documents, they make what's going on very explicit. >> >> > Thanks! > > >> Do you have a pointer to a test that rely on this feature? I'd like to >> give this patch a spin. >> > > For example, anything in hotspot/jtreg/runtime, e.g. > runtime/ErrorHandling. Alternatively, you could grep for "import > jdk.test.lib.process". There are some tests in the jdk too. > > Cheers, Thomas > > >> >> Cheers >> Maurizio >> >> On 29/01/2019 14:06, Thomas St?fe wrote: >> > Greetings, >> > >> > May I please have your opinions about the following fix: >> > >> > bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 >> > cr: >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ >> > >> > jtreg tests containing references to external test libraries (e.g. >> @library >> > /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and >> > references to those test support classes will not be resolved and >> result in >> > red wiggly lines in Intellij. This affects mostly jtreg tests for the >> > hotspot, since those typically rely on /test/lib. >> > >> > This patch causes the Intellij jtreg plugin properly recognize and >> handle >> > the external.lib.roots entry in the test suite configuration files. The >> > TEST.ROOT file for an opened source is parsed and the external library >> path >> > extracted. I am not sure whether this is the best way to go about it or >> > whether this is too expensive though. The parsing is only done for the >> > first file under a given TEST.ROOT, so it should be okay? >> > >> > The plugin works for me, on a quite underpowered ultrabook. Note that I >> > also added a lot of logging, all debug level, to aid me in development. >> If >> > necessary I can remove it but would prefer not to. >> > >> > Please note that I'm quite new to jtreg plugin development as well as to >> > the jtreg internals, so I may miss something obvious. Would appreciate >> it >> > if someone more knowledgeable reviews it (Maurizio?). >> > >> > Thanks & Best Regards, Thomas >> > From jonathan.gibbons at oracle.com Wed Jan 30 18:17:42 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 Jan 2019 10:17:42 -0800 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> Message-ID: <169cbb31-384b-3471-4fb1-45965f83a1d9@oracle.com> If Maurizio approves, you're good to go, although you're not a CodeTools committer, and will need someone (e.g. him or me) to push for you. -- Jon On 1/30/19 9:24 AM, Thomas St?fe wrote: > Thanks Maurizio. I'll prepare another webrev, but probably not before next > week. > > Do I need a second reviewer for codetool patches? > > Cheers, Thomas > > On Wed, Jan 30, 2019 at 5:27 PM Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> The patch seems to be working correctly - I used it in my existing project >> and it seems to work fine. >> >> As for the review, you need to bump the jtreg plugin version, e.g. like >> this: >> >> --- a/plugins/idea/resources/META-INF/plugin.xml Tue Jan 29 >> 15:11:03 2019 -0800 >> +++ b/plugins/idea/resources/META-INF/plugin.xml Wed Jan 30 >> 16:27:18 2019 +0000 >> @@ -26,13 +26,13 @@ >> >> jtreg >> jtreg Test Support >> - 1.8 >> + 1.9 >> > Allows execution of tests developed using the > "http://openjdk.java.net/jtreg/" >jtreg >> framework. >> ]]> >> >> > - Add support for IntelliJ IDE2018.3 >> + Allow support for external library resolution >> ]]> >> >> >> >> Thanks >> Maurizio >> On 29/01/2019 14:32, Thomas St?fe wrote: >> >> >> On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> Hi, >>> this looks like a solid piece of work; thanks for adding all the >>> documents, they make what's going on very explicit. >>> >>> >> Thanks! >> >> >>> Do you have a pointer to a test that rely on this feature? I'd like to >>> give this patch a spin. >>> >> For example, anything in hotspot/jtreg/runtime, e.g. >> runtime/ErrorHandling. Alternatively, you could grep for "import >> jdk.test.lib.process". There are some tests in the jdk too. >> >> Cheers, Thomas >> >> >>> Cheers >>> Maurizio >>> >>> On 29/01/2019 14:06, Thomas St?fe wrote: >>>> Greetings, >>>> >>>> May I please have your opinions about the following fix: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 >>>> cr: >>>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ >>>> jtreg tests containing references to external test libraries (e.g. >>> @library >>>> /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and >>>> references to those test support classes will not be resolved and >>> result in >>>> red wiggly lines in Intellij. This affects mostly jtreg tests for the >>>> hotspot, since those typically rely on /test/lib. >>>> >>>> This patch causes the Intellij jtreg plugin properly recognize and >>> handle >>>> the external.lib.roots entry in the test suite configuration files. The >>>> TEST.ROOT file for an opened source is parsed and the external library >>> path >>>> extracted. I am not sure whether this is the best way to go about it or >>>> whether this is too expensive though. The parsing is only done for the >>>> first file under a given TEST.ROOT, so it should be okay? >>>> >>>> The plugin works for me, on a quite underpowered ultrabook. Note that I >>>> also added a lot of logging, all debug level, to aid me in development. >>> If >>>> necessary I can remove it but would prefer not to. >>>> >>>> Please note that I'm quite new to jtreg plugin development as well as to >>>> the jtreg internals, so I may miss something obvious. Would appreciate >>> it >>>> if someone more knowledgeable reviews it (Maurizio?). >>>> >>>> Thanks & Best Regards, Thomas From jonathan.gibbons at oracle.com Thu Jan 31 01:02:33 2019 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 31 Jan 2019 01:02:33 +0000 Subject: hg: code-tools/jtreg: 7902375: Update bin/jtreg script to support Windows Subsystem for Linux (WSL) Message-ID: <201901310102.x0V12Xfv007181@aojmv0008.oracle.com> Changeset: 7a14d878d20f Author: jjg Date: 2019-01-30 17:02 -0800 URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/7a14d878d20f 7902375: Update bin/jtreg script to support Windows Subsystem for Linux (WSL) ! src/share/bin/jtreg.sh From jonathan.gibbons at oracle.com Thu Jan 31 01:45:21 2019 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 30 Jan 2019 17:45:21 -0800 Subject: hg: code-tools/jtreg: 7902375: Update bin/jtreg script to support Windows Subsystem for Linux (WSL) In-Reply-To: <201901310102.x0V12Xfv007181@aojmv0008.oracle.com> References: <201901310102.x0V12Xfv007181@aojmv0008.oracle.com> Message-ID: <24584d06-d5da-4587-490b-0dcba6649801@oracle.com> For those that may be interested, I've posted an update for the bin/jtreg script, to fix it to work on WSL. It should support all combinations of using a Windows or Linux JDK to run jtreg, and to test a Windows or Linux JDK.? I've also refactored the code to tidy up the necessary work for both Cygwin and WSL. Tested on standard Linux, Cygwin and WSL with a Windows JDK. The need for the -wsl command line option is "annoying", and caught me out a few times during testing. I'll enhance that code to improve the default behavior. I've filed CODETOOLS-7902376 for that. -- Jon On 01/30/2019 05:02 PM, jonathan.gibbons at oracle.com wrote: > Changeset: 7a14d878d20f > Author: jjg > Date: 2019-01-30 17:02 -0800 > URL: http://hg.openjdk.java.net/code-tools/jtreg/rev/7a14d878d20f > > 7902375: Update bin/jtreg script to support Windows Subsystem for Linux (WSL) > > ! src/share/bin/jtreg.sh > From maurizio.cimadamore at oracle.com Thu Jan 31 14:30:34 2019 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 31 Jan 2019 14:30:34 +0000 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: <169cbb31-384b-3471-4fb1-45965f83a1d9@oracle.com> References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> <169cbb31-384b-3471-4fb1-45965f83a1d9@oracle.com> Message-ID: <46310a19-be73-a9dd-6c69-ffa9c1dfa2b2@oracle.com> I'm happy to push it for you when you have the final changeset. Thanks! Maurizio On 30/01/2019 18:17, Jonathan Gibbons wrote: > If Maurizio approves, you're good to go, although you're not a > CodeTools committer, and will need someone (e.g. him or me) to push > for you. > > -- Jon > > On 1/30/19 9:24 AM, Thomas St?fe wrote: >> Thanks Maurizio. I'll prepare another webrev, but probably not before >> next >> week. >> >> Do I need a second reviewer for codetool patches? >> >> Cheers, Thomas >> >> On Wed, Jan 30, 2019 at 5:27 PM Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> The patch seems to be working correctly - I used it in my existing >>> project >>> and it seems to work fine. >>> >>> As for the review, you need to bump the jtreg plugin version, e.g. like >>> this: >>> >>> --- a/plugins/idea/resources/META-INF/plugin.xml??????? Tue Jan 29 >>> 15:11:03 2019 -0800 >>> +++ b/plugins/idea/resources/META-INF/plugin.xml??????? Wed Jan 30 >>> 16:27:18 2019 +0000 >>> @@ -26,13 +26,13 @@ >>> ? >>> ????? jtreg >>> ????? jtreg Test Support >>> -??? 1.8 >>> +??? 1.9 >>> ????? >> ??????? Allows execution of tests developed using the >> "http://openjdk.java.net/jtreg/" >>> >jtreg >>> framework. >>> ????? ]]> >>> >>> ????? >> -????? Add support for IntelliJ IDE2018.3 >>> +????? Allow support for external library resolution >>> ????? ]]> >>> ????? >>> >>> >>> Thanks >>> Maurizio >>> On 29/01/2019 14:32, Thomas St?fe wrote: >>> >>> >>> On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> Hi, >>>> this looks like a solid piece of work; thanks for adding all the >>>> documents, they make what's going on very explicit. >>>> >>>> >>> Thanks! >>> >>> >>>> Do you have a pointer to a test that rely on this feature? I'd like to >>>> give this patch a spin. >>>> >>> For example, anything in hotspot/jtreg/runtime, e.g. >>> runtime/ErrorHandling. Alternatively, you could grep for "import >>> jdk.test.lib.process". There are some tests in the jdk too. >>> >>> Cheers, Thomas >>> >>> >>>> Cheers >>>> Maurizio >>>> >>>> On 29/01/2019 14:06, Thomas St?fe wrote: >>>>> Greetings, >>>>> >>>>> May I please have your opinions about the following fix: >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 >>>>> cr: >>>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ >>>> >>>>> jtreg tests containing references to external test libraries (e.g. >>>> @library >>>>> /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and >>>>> references to those test support classes will not be resolved and >>>> result in >>>>> red wiggly lines in Intellij. This affects mostly jtreg tests for the >>>>> hotspot, since those typically rely on /test/lib. >>>>> >>>>> This patch causes the Intellij jtreg plugin properly recognize and >>>> handle >>>>> the external.lib.roots entry in the test suite configuration >>>>> files. The >>>>> TEST.ROOT file for an opened source is parsed and the external >>>>> library >>>> path >>>>> extracted. I am not sure whether this is the best way to go about >>>>> it or >>>>> whether this is too expensive though. The parsing is only done for >>>>> the >>>>> first file under a given TEST.ROOT, so it should be okay? >>>>> >>>>> The plugin works for me, on a quite underpowered ultrabook. Note >>>>> that I >>>>> also added a lot of logging, all debug level, to aid me in >>>>> development. >>>> If >>>>> necessary I can remove it but would prefer not to. >>>>> >>>>> Please note that I'm quite new to jtreg plugin development as well >>>>> as to >>>>> the jtreg internals, so I may miss something obvious. Would >>>>> appreciate >>>> it >>>>> if someone more knowledgeable reviews it (Maurizio?). >>>>> >>>>> Thanks & Best Regards, Thomas From thomas.stuefe at gmail.com Thu Jan 31 14:56:51 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Jan 2019 15:56:51 +0100 Subject: RFR: CODETOOLS-7902373: Intellij jtreg plugin fails to resolve external libraries In-Reply-To: <46310a19-be73-a9dd-6c69-ffa9c1dfa2b2@oracle.com> References: <5baa72a7-762b-8152-e368-60bb7bfcfe07@oracle.com> <03c54c68-f0ea-4de2-b4ab-67fec3c5eba2@oracle.com> <169cbb31-384b-3471-4fb1-45965f83a1d9@oracle.com> <46310a19-be73-a9dd-6c69-ffa9c1dfa2b2@oracle.com> Message-ID: Great, here you go: http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.01/webrev/ Only minor stuff changed: - added change note as you suggested (found that
    is needed to make it look good in the settings dialog though) - bumped version to 1.9 - corrected copyright dates Thank you for pushing! My census name is "stuefe", if that is important. Cheers, Thomas On Thu, Jan 31, 2019 at 3:30 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I'm happy to push it for you when you have the final changeset. > > Thanks! > Maurizio > > On 30/01/2019 18:17, Jonathan Gibbons wrote: > > If Maurizio approves, you're good to go, although you're not a > > CodeTools committer, and will need someone (e.g. him or me) to push > > for you. > > > > -- Jon > > > > On 1/30/19 9:24 AM, Thomas St?fe wrote: > >> Thanks Maurizio. I'll prepare another webrev, but probably not before > >> next > >> week. > >> > >> Do I need a second reviewer for codetool patches? > >> > >> Cheers, Thomas > >> > >> On Wed, Jan 30, 2019 at 5:27 PM Maurizio Cimadamore < > >> maurizio.cimadamore at oracle.com> wrote: > >> > >>> The patch seems to be working correctly - I used it in my existing > >>> project > >>> and it seems to work fine. > >>> > >>> As for the review, you need to bump the jtreg plugin version, e.g. like > >>> this: > >>> > >>> --- a/plugins/idea/resources/META-INF/plugin.xml Tue Jan 29 > >>> 15:11:03 2019 -0800 > >>> +++ b/plugins/idea/resources/META-INF/plugin.xml Wed Jan 30 > >>> 16:27:18 2019 +0000 > >>> @@ -26,13 +26,13 @@ > >>> > >>> jtreg > >>> jtreg Test Support > >>> - 1.8 > >>> + 1.9 > >>> >>> Allows execution of tests developed using the >>> "http://openjdk.java.net/jtreg/" > >>> >jtreg > >>> framework. > >>> ]]> > >>> > >>> >>> - Add support for IntelliJ IDE2018.3 > >>> + Allow support for external library resolution > >>> ]]> > >>> > >>> > >>> > >>> Thanks > >>> Maurizio > >>> On 29/01/2019 14:32, Thomas St?fe wrote: > >>> > >>> > >>> On Tue, Jan 29, 2019 at 3:24 PM Maurizio Cimadamore < > >>> maurizio.cimadamore at oracle.com> wrote: > >>> > >>>> Hi, > >>>> this looks like a solid piece of work; thanks for adding all the > >>>> documents, they make what's going on very explicit. > >>>> > >>>> > >>> Thanks! > >>> > >>> > >>>> Do you have a pointer to a test that rely on this feature? I'd like to > >>>> give this patch a spin. > >>>> > >>> For example, anything in hotspot/jtreg/runtime, e.g. > >>> runtime/ErrorHandling. Alternatively, you could grep for "import > >>> jdk.test.lib.process". There are some tests in the jdk too. > >>> > >>> Cheers, Thomas > >>> > >>> > >>>> Cheers > >>>> Maurizio > >>>> > >>>> On 29/01/2019 14:06, Thomas St?fe wrote: > >>>>> Greetings, > >>>>> > >>>>> May I please have your opinions about the following fix: > >>>>> > >>>>> bug: https://bugs.openjdk.java.net/browse/CODETOOLS-7902373 > >>>>> cr: > >>>>> > >>>> > http://cr.openjdk.java.net/~stuefe/webrevs/codetools-7902373--intellij-jtreg-plugin-fails-to-resolve-external-libraries/webrev.00/webrev/ > >>>> > >>>>> jtreg tests containing references to external test libraries (e.g. > >>>> @library > >>>>> /test/lib) are not properly handled(e.g. jdk.test.lib.process.*), and > >>>>> references to those test support classes will not be resolved and > >>>> result in > >>>>> red wiggly lines in Intellij. This affects mostly jtreg tests for the > >>>>> hotspot, since those typically rely on /test/lib. > >>>>> > >>>>> This patch causes the Intellij jtreg plugin properly recognize and > >>>> handle > >>>>> the external.lib.roots entry in the test suite configuration > >>>>> files. The > >>>>> TEST.ROOT file for an opened source is parsed and the external > >>>>> library > >>>> path > >>>>> extracted. I am not sure whether this is the best way to go about > >>>>> it or > >>>>> whether this is too expensive though. The parsing is only done for > >>>>> the > >>>>> first file under a given TEST.ROOT, so it should be okay? > >>>>> > >>>>> The plugin works for me, on a quite underpowered ultrabook. Note > >>>>> that I > >>>>> also added a lot of logging, all debug level, to aid me in > >>>>> development. > >>>> If > >>>>> necessary I can remove it but would prefer not to. > >>>>> > >>>>> Please note that I'm quite new to jtreg plugin development as well > >>>>> as to > >>>>> the jtreg internals, so I may miss something obvious. Would > >>>>> appreciate > >>>> it > >>>>> if someone more knowledgeable reviews it (Maurizio?). > >>>>> > >>>>> Thanks & Best Regards, Thomas >