From duke at openjdk.org  Mon Feb  3 16:12:06 2025
From: duke at openjdk.org (duke)
Date: Mon, 3 Feb 2025 16:12:06 GMT
Subject: RFR: 7903931: Add "test.thread.factory" property to filter tests
 based on test thread factory value [v3]
In-Reply-To: <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
 <1YiDuxUHNV0aUTHxtnEWysuL5Q80OG-jM_PdjQaQAwM=.5d91a8ce-00b4-42da-a316-461b75a8500b@github.com>
Message-ID: <aJowJ5f28Fv5ttZCim4pingUDbDVWuCyx_XZ19l46EU=.a316768e-c5f0-4b58-87e0-cd2907b64584@github.com>

On Tue, 28 Jan 2025 17:47:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
>> 
>> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
>> 
>> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
>> 
>> The only jtreg knows if -testThreadFactory is set so it should set corresponding property
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test.thread.factory is not a property for tag spec

@lmesnik 
Your change (at version 338694bccf7b2f00a29e2427cd38970a87151bec) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/242#issuecomment-2631439569

From lmesnik at openjdk.org  Tue Feb  4 08:00:32 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 4 Feb 2025 08:00:32 GMT
Subject: Integrated: 7903931: Add "test.thread.factory" property to filter
 tests based on test thread factory value
In-Reply-To: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
References: <HHF8pXbG7auWY-YODaMD5e5HNiT8sXxYzlPSDztbrbA=.eb0f38ff-60da-4cc8-90cc-8b4080862316@github.com>
Message-ID: <Cb5azPyDAkXLpaONT29vLGnbGFarY1-a9ziq41ixpCc=.03513dc5-459d-4358-bf18-7d39a85143bf@github.com>

On Tue, 14 Jan 2025 04:06:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> jtreg support test thread factory parameter that allows to execute tests by running main in virtual thread.
> 
> Currently, all incompatible tests are problemlisted. However after security manager removal the number of such tests is small.
> 
> So is it makes sense to add "jtreg.ttf" property to filter tests based on test thread factory value to allow filter out incompatible tests.
> 
> The only jtreg knows if -testThreadFactory is set so it should set corresponding property

This pull request has now been integrated.

Changeset: 919e0896
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/919e089674ada69bf0760383d7f2383cdc272d69
Stats:     8 lines in 2 files changed: 6 ins; 0 del; 2 mod

7903931: Add "test.thread.factory" property to filter tests based on test thread factory value

Reviewed-by: cstein, iris

-------------

PR: https://git.openjdk.org/jtreg/pull/242

From cstein at openjdk.org  Tue Feb  4 09:50:07 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 09:50:07 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1
Message-ID: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>

Please review this change preparing the `7.5.1` release of `jtreg`.

The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.

This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.

-------------

Commit messages:
 - 7903943: Release jtreg 7.5.1

Changes: https://git.openjdk.org/jtreg/pull/245/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=245&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903943
  Stats: 15 lines in 2 files changed: 9 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/245.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/245/head:pull/245

PR: https://git.openjdk.org/jtreg/pull/245

From cstein at openjdk.org  Tue Feb  4 11:16:25 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 11:16:25 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v2]
In-Reply-To: <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>
Message-ID: <9biiSchHgr_Nmd-RlJtAXqAQSaikzP5icaX6ILGmoeI=.92780d21-86e8-4446-9efc-98c6f9e4ebdd@github.com>

On Wed, 29 Jan 2025 19:15:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
>> 
>> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
>> 
>> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use qualified class name, for the sake of nested test classes

Seeing more errors with the Gradle Wrapper check lately. Anything we can do about it in this PR?

https://github.com/sormuras/jtreg/actions/runs/13132506775/job/36640486792

![image](https://github.com/user-attachments/assets/88d3c64b-2263-465b-ad6c-57893cb475c0)

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/240#issuecomment-2633593805

From jpai at openjdk.org  Tue Feb  4 11:17:24 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Feb 2025 11:17:24 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1
In-Reply-To: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
Message-ID: <qzzRDP2Twy6RGckOz678YZrAcBL3Nt8YAaoU_WAx7CA=.9d469c0e-cc4f-42f3-a3ac-30c9f1e83ae9@github.com>

On Tue, 4 Feb 2025 09:44:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change preparing the `7.5.1` release of `jtreg`.
> 
> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
> 
> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.

Overall looks good to me. The `make/build-support/version-numbers` file will need a copyright year update before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2592503677

From cstein at openjdk.org  Tue Feb  4 11:30:18 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 11:30:18 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v2]
In-Reply-To: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
Message-ID: <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>

> Please review this change preparing the `7.5.1` release of `jtreg`.
> 
> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
> 
> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.

Christian Stein has updated the pull request incrementally with two additional commits since the last revision:

 - Update Gradle Wrapper validation action
 - Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/245/files
  - new: https://git.openjdk.org/jtreg/pull/245/files/1703504c..c1c5b3ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=245&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=245&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/245.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/245/head:pull/245

PR: https://git.openjdk.org/jtreg/pull/245

From jpai at openjdk.org  Tue Feb  4 11:30:18 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 4 Feb 2025 11:30:18 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v2]
In-Reply-To: <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
Message-ID: <ZBVX1evpAeBIQGVb8ZVv8pK27t7AwG3yi5zDMqFq3Bo=.fd178147-4d10-4dd1-ae62-a8432c6b8dbd@github.com>

On Tue, 4 Feb 2025 11:25:31 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Gradle Wrapper validation action
>  - Update copyright year

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2592532782

From jvernee at openjdk.org  Tue Feb  4 11:44:22 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Feb 2025 11:44:22 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v2]
In-Reply-To: <9biiSchHgr_Nmd-RlJtAXqAQSaikzP5icaX6ILGmoeI=.92780d21-86e8-4446-9efc-98c6f9e4ebdd@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>
 <9biiSchHgr_Nmd-RlJtAXqAQSaikzP5icaX6ILGmoeI=.92780d21-86e8-4446-9efc-98c6f9e4ebdd@github.com>
Message-ID: <QGbvGNH_ru9fkQXMAqeRuVlSQJTCcLmnlG8nLX2gMjc=.fcf75a34-eb05-4714-a878-5d978ec6cb4e@github.com>

On Tue, 4 Feb 2025 11:12:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Anything we can do about it in this PR?

I can change the action to the new one if you want.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/240#issuecomment-2633658371

From cstein at openjdk.org  Tue Feb  4 11:52:22 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 11:52:22 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v2]
In-Reply-To: <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <bQwAHArOV47JdvykdsibgP2UOrox7xelZtN81LdKSnk=.640b3850-4e0a-4da3-a474-e5e5d3879ef6@github.com>
Message-ID: <mJLAwXdAMD7CjCll2-V9yKMUQlVXTdDX5SsOMWrq7Xo=.1ba0e979-1e08-47dc-9bc0-31680a84d936@github.com>

On Wed, 29 Jan 2025 19:15:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
>> 
>> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
>> 
>> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use qualified class name, for the sake of nested test classes

That'd be great!

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/240#issuecomment-2633673878

From jvernee at openjdk.org  Tue Feb  4 12:26:10 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 4 Feb 2025 12:26:10 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v3]
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <HZz2sVRIVoJKPlaumKvE_lL2Fy7QhBzmFwQKdZI9ROE=.966b2ace-bc95-4cf0-9a00-0fd2121131cf@github.com>

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update wrapper validation action

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/240/files
  - new: https://git.openjdk.org/jtreg/pull/240/files/d9e8947a..33c03a77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/240.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/240/head:pull/240

PR: https://git.openjdk.org/jtreg/pull/240

From iris at openjdk.org  Tue Feb  4 17:39:32 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Feb 2025 17:39:32 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v2]
In-Reply-To: <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
Message-ID: <Iq0m01ggRA1Oip9ZDwqVBa4BK6PAfbT9BayVzp7ix6E=.05d9cef5-f48f-4502-8ff4-b6847f1ef313@github.com>

On Tue, 4 Feb 2025 11:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Gradle Wrapper validation action
>  - Update copyright year

Looks good!

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2593583546

From rriggs at openjdk.org  Tue Feb  4 18:29:25 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 18:29:25 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v2]
In-Reply-To: <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
Message-ID: <aDgbJ1p0nKL51sXtOXacFraWChmoM6-8F8PlWlHcCdE=.8e8676ee-eeb1-47d8-aed0-ee452a37628b@github.com>

On Tue, 4 Feb 2025 11:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Gradle Wrapper validation action
>  - Update copyright year

Should there be an update to tag-spec.html to remove the mention of LIBRARY.properties/

-------------

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2593717645

From cstein at openjdk.org  Tue Feb  4 18:35:38 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 18:35:38 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v2]
In-Reply-To: <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <O2EJbO3DiARWPazw2gC-51j0K67NS4JvRBbJN_O7ohQ=.43ae2d0f-eaa8-49e7-b3a1-bff2253c949c@github.com>
Message-ID: <Q02_77Zp1XW4ZiM9W6hVJ2Hsave3b0HVxA1x7YD9y6o=.e0aa62ec-4ee2-47f6-b499-b77d985c90da@github.com>

On Tue, 4 Feb 2025 11:30:18 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Gradle Wrapper validation action
>  - Update copyright year

Good catch, Roger!

I'll remove all occurances of `LIBRARY.properties` from `tag-spec.html` and also from the `faq.md` file.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/245#issuecomment-2634761008

From cstein at openjdk.org  Tue Feb  4 18:41:34 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 18:41:34 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v3]
In-Reply-To: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
Message-ID: <Qc2zjptgVuaoEvJS4-d_5hgAm0CSGvKnZpT1qGR2rM8=.dc15bca0-1277-4f14-bc52-da7e354835a1@github.com>

> Please review this change preparing the `7.5.1` release of `jtreg`.
> 
> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
> 
> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Remove last traces of `LIBRARY.properties`

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/245/files
  - new: https://git.openjdk.org/jtreg/pull/245/files/c1c5b3ae..124b5afc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=245&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=245&range=01-02

  Stats: 28 lines in 2 files changed: 0 ins; 28 del; 0 mod
  Patch: https://git.openjdk.org/jtreg/pull/245.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/245/head:pull/245

PR: https://git.openjdk.org/jtreg/pull/245

From rriggs at openjdk.org  Tue Feb  4 19:33:28 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Feb 2025 19:33:28 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v3]
In-Reply-To: <Qc2zjptgVuaoEvJS4-d_5hgAm0CSGvKnZpT1qGR2rM8=.dc15bca0-1277-4f14-bc52-da7e354835a1@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <Qc2zjptgVuaoEvJS4-d_5hgAm0CSGvKnZpT1qGR2rM8=.dc15bca0-1277-4f14-bc52-da7e354835a1@github.com>
Message-ID: <5jTUNQw1soxLIQ5D5xcEC1JAwpUdLZrNTgkeO8ZGiJU=.9911eb36-8ae7-4b48-ae05-1582bdc12e87@github.com>

On Tue, 4 Feb 2025 18:41:34 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove last traces of `LIBRARY.properties`

Non Reviewer;  looks good.

-------------

Marked as reviewed by rriggs (no project role).

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2593850169

From iris at openjdk.org  Tue Feb  4 19:45:29 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Feb 2025 19:45:29 GMT
Subject: RFR: 7903943: Release jtreg 7.5.1 [v3]
In-Reply-To: <Qc2zjptgVuaoEvJS4-d_5hgAm0CSGvKnZpT1qGR2rM8=.dc15bca0-1277-4f14-bc52-da7e354835a1@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
 <Qc2zjptgVuaoEvJS4-d_5hgAm0CSGvKnZpT1qGR2rM8=.dc15bca0-1277-4f14-bc52-da7e354835a1@github.com>
Message-ID: <_yf_iAa9IofC1Wp0bhD6JGOsdIk1O7NIXg5Uh-L_e24=.449021e8-f04e-4837-8155-94d0d60abe92@github.com>

On Tue, 4 Feb 2025 18:41:34 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change preparing the `7.5.1` release of `jtreg`.
>> 
>> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
>> 
>> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove last traces of `LIBRARY.properties`

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jtreg/pull/245#pullrequestreview-2593873073

From cstein at openjdk.org  Tue Feb  4 21:48:22 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 4 Feb 2025 21:48:22 GMT
Subject: Integrated: 7903943: Release jtreg 7.5.1
In-Reply-To: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
References: <EemC4uaQ9p5FiZm3ZBJQp9LJafeW3XPBeBdas7i3YjQ=.414eea96-5656-4434-bce6-583401341dcc@github.com>
Message-ID: <zxEV0PN4pF030P4dRJwIlpbC8_g7L5vLtzpUGFAb4F0=.35cb6fde-a2c9-4fa7-a85e-60ea914c790c@github.com>

On Tue, 4 Feb 2025 09:44:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change preparing the `7.5.1` release of `jtreg`.
> 
> The version number `7.6` will be restored on the main branch after the release; a dedidated `7.5.x` branch was not required, yet.
> 
> This change also updates the `CHANGELOG.md` file with noteworthy items. It also removes the detailed description of the now removed `LIBRARY.properties` support from the `7.5` section.

This pull request has now been integrated.

Changeset: 8e4d9b49
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/8e4d9b493d962f48365c1dcc4df2ea248031859a
Stats:     45 lines in 5 files changed: 9 ins; 32 del; 4 mod

7903943: Release jtreg 7.5.1

Reviewed-by: jpai, iris, rriggs

-------------

PR: https://git.openjdk.org/jtreg/pull/245

From cstein at openjdk.org  Wed Feb  5 08:05:55 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 5 Feb 2025 08:05:55 GMT
Subject: RFR: 7903944: Update version to 7.6
Message-ID: <jDcR4TZQ6sUXfgPkGf07rW9dEAUGwyXUb5DB6MR_als=.d7834630-430b-4521-a8fb-763e469f20b4@github.com>

Please review this trivial change updating the version to `7.6`; the upcoming release version of `jtreg`.

-------------

Commit messages:
 - 7903944: Update version to 7.6

Changes: https://git.openjdk.org/jtreg/pull/246/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=246&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903944
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/246.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/246/head:pull/246

PR: https://git.openjdk.org/jtreg/pull/246

From jpai at openjdk.org  Wed Feb  5 08:05:55 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Feb 2025 08:05:55 GMT
Subject: RFR: 7903944: Update version to 7.6
In-Reply-To: <jDcR4TZQ6sUXfgPkGf07rW9dEAUGwyXUb5DB6MR_als=.d7834630-430b-4521-a8fb-763e469f20b4@github.com>
References: <jDcR4TZQ6sUXfgPkGf07rW9dEAUGwyXUb5DB6MR_als=.d7834630-430b-4521-a8fb-763e469f20b4@github.com>
Message-ID: <jKsXkA4PgrSUiDyKhbuhjH2XFX-433Nx2GQGSwnHqnA=.45d32d0a-6378-4be3-a688-4f4fc9516eb8@github.com>

On Wed, 5 Feb 2025 07:59:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this trivial change updating the version to `7.6`; the upcoming release version of `jtreg`.

Looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/246#pullrequestreview-2594894793

From cstein at openjdk.org  Wed Feb  5 08:13:30 2025
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 5 Feb 2025 08:13:30 GMT
Subject: Integrated: 7903944: Update version to 7.6
In-Reply-To: <jDcR4TZQ6sUXfgPkGf07rW9dEAUGwyXUb5DB6MR_als=.d7834630-430b-4521-a8fb-763e469f20b4@github.com>
References: <jDcR4TZQ6sUXfgPkGf07rW9dEAUGwyXUb5DB6MR_als=.d7834630-430b-4521-a8fb-763e469f20b4@github.com>
Message-ID: <ezGPA58rOvou5oZy-UlVvTh8cJZ6b_zCAhd5duwJUI8=.9e46f05a-fd4b-43d3-8c7f-e427e52d3eba@github.com>

On Wed, 5 Feb 2025 07:59:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this trivial change updating the version to `7.6`; the upcoming release version of `jtreg`.

This pull request has now been integrated.

Changeset: 3865c9f1
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/3865c9f1dddc103e2790790f9e359af2007b869e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

7903944: Update version to 7.6

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jtreg/pull/246

From jvernee at openjdk.org  Thu Feb  6 14:36:40 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 14:36:40 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v4]
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
> 
> Here is a picture of what the new configuration UI looks like:
> 
> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
> 
> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into RunMethods
 - update notes
 - Update wrapper validation action
 - Use qualified class name, for the sake of nested test classes
 - move query string text field + tie to file selection
 - use new query string format
 - Support query string in idea plugin

-------------

Changes: https://git.openjdk.org/jtreg/pull/240/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=03
  Stats: 167 lines in 8 files changed: 138 ins; 9 del; 20 mod
  Patch: https://git.openjdk.org/jtreg/pull/240.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/240/head:pull/240

PR: https://git.openjdk.org/jtreg/pull/240

From mcimadamore at openjdk.org  Thu Feb  6 14:48:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 6 Feb 2025 14:48:27 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v4]
In-Reply-To: <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>
Message-ID: <qlXq6Z0lVI1AR2xuF_w1h9_vOtLAPlh_UkAFzwhiRjU=.b380849d-064c-4441-8306-c1a7094a5414@github.com>

On Thu, 6 Feb 2025 14:36:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
>> 
>> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
>> 
>> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
>> 
>> Here is a picture of what the new configuration UI looks like:
>> 
>> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
>> 
>> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into RunMethods
>  - update notes
>  - Update wrapper validation action
>  - Use qualified class name, for the sake of nested test classes
>  - move query string text field + tie to file selection
>  - use new query string format
>  - Support query string in idea plugin

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 69:

> 67:     }
> 68: 
> 69:     private static String nameForElement(PsiElement element) {

What are these changes for? These seems unrelated to the binary name problem?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/240#discussion_r1944855656

From mcimadamore at openjdk.org  Thu Feb  6 15:00:27 2025
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 6 Feb 2025 15:00:27 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v4]
In-Reply-To: <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>
Message-ID: <6yeyycklQrgnVGW7T315nZvBPqToHtRAAJ5vqHcucr8=.746ad4b6-7aa7-4374-896a-0bca4b22d4df@github.com>

On Thu, 6 Feb 2025 14:36:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
>> 
>> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
>> 
>> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
>> 
>> Here is a picture of what the new configuration UI looks like:
>> 
>> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
>> 
>> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into RunMethods
>  - update notes
>  - Update wrapper validation action
>  - Use qualified class name, for the sake of nested test classes
>  - move query string text field + tie to file selection
>  - use new query string format
>  - Support query string in idea plugin

Very nice extension, thanks!

plugins/idea/gradle.properties line 7:

> 5: # https://plugins.jetbrains.com/plugin/23025-ant
> 6: antSupportVersion = 242.20224.159
> 7: pluginVersion = 1.17

bump version please

plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegConfigurationProducer.java line 131:

> 129:         String qualName = cls.getQualifiedName();
> 130:         String packageName = qualName.substring(0, qualName.length() - nestedName.length());
> 131:         return packageName + nestedName.replace('.', '$');

Boy this is pretty ugly (not your fault - can't find a way to get package from class)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/240#pullrequestreview-2598937341
PR Review Comment: https://git.openjdk.org/jtreg/pull/240#discussion_r1944874960
PR Review Comment: https://git.openjdk.org/jtreg/pull/240#discussion_r1944874514

From jvernee at openjdk.org  Thu Feb  6 16:00:27 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 16:00:27 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v4]
In-Reply-To: <qlXq6Z0lVI1AR2xuF_w1h9_vOtLAPlh_UkAFzwhiRjU=.b380849d-064c-4441-8306-c1a7094a5414@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <5nxwNWP2xceUPMWlIZuj2x3OT9CXq1NREKjH8EAFLpA=.36e0c852-1d48-4d7d-a849-9f0ee87074f1@github.com>
 <qlXq6Z0lVI1AR2xuF_w1h9_vOtLAPlh_UkAFzwhiRjU=.b380849d-064c-4441-8306-c1a7094a5414@github.com>
Message-ID: <0GDcOAoqjIZ6gxQLi-2EWpq1pQBnOTg8sSh26dTVuno=.c7106fea-bc22-450c-9cfa-fab9e3266b96@github.com>

On Thu, 6 Feb 2025 14:45:35 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'master' into RunMethods
>>  - update notes
>>  - Update wrapper validation action
>>  - Use qualified class name, for the sake of nested test classes
>>  - move query string text field + tie to file selection
>>  - use new query string format
>>  - Support query string in idea plugin
>
> plugins/idea/src/main/java/com/oracle/plugin/jtreg/configuration/producers/JTRegClassConfigurationProducer.java line 69:
> 
>> 67:     }
>> 68: 
>> 69:     private static String nameForElement(PsiElement element) {
> 
> What are these changes for? These seems unrelated to the binary name problem?

These are creating a name for the run configuration. For instance, currently when you create a run configuration, it will always have the same name as the file, but with these changes, when you create a configuration for a method, the name will be e.g. `TestDowncallScope::testDowncall`. This should make it easier to tell apart a run configuration for a whole class from one for an individual method.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/240#discussion_r1944982832

From jvernee at openjdk.org  Thu Feb  6 16:04:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 16:04:48 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v5]
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <odpuXQ5jq1Vwmyx7g23hD7WQxu3sxgFac4MKaNKGf04=.dec74f55-d5e2-47cb-a054-e2be1da8b6ab@github.com>

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
> 
> Here is a picture of what the new configuration UI looks like:
> 
> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
> 
> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  increment plugin version

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/240/files
  - new: https://git.openjdk.org/jtreg/pull/240/files/3915f74c..2d138fe3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=04
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/240.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/240/head:pull/240

PR: https://git.openjdk.org/jtreg/pull/240

From jvernee at openjdk.org  Thu Feb  6 16:58:38 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 16:58:38 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v5]
In-Reply-To: <odpuXQ5jq1Vwmyx7g23hD7WQxu3sxgFac4MKaNKGf04=.dec74f55-d5e2-47cb-a054-e2be1da8b6ab@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
 <odpuXQ5jq1Vwmyx7g23hD7WQxu3sxgFac4MKaNKGf04=.dec74f55-d5e2-47cb-a054-e2be1da8b6ab@github.com>
Message-ID: <eyaF0PkpVqQb2IQN3uruVu6fO0YGaWhoTe-vteDrXI4=.ac81c820-92b6-41e8-81ab-4c59dfe086f8@github.com>

On Thu, 6 Feb 2025 16:04:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
>> 
>> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
>> 
>> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
>> 
>> Here is a picture of what the new configuration UI looks like:
>> 
>> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
>> 
>> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   increment plugin version

I've bumped the copyright years as well [688a8fb](https://github.com/openjdk/jtreg/pull/240/commits/688a8fb61c1416b6b14c47b0559d8e89ec7b0d9f)

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/240#issuecomment-2640464523

From jvernee at openjdk.org  Thu Feb  6 16:58:38 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 16:58:38 GMT
Subject: RFR: 7903934: Add support for query strings to the IntelliJ plugin
 [v6]
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <1y84vSx7EgWD0jVtbqe7rEAlx9BhLRjJ-dXUwcKIaS8=.659c50e1-3e7d-4b59-aaba-cfbe09fac14b@github.com>

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
> 
> Here is a picture of what the new configuration UI looks like:
> 
> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
> 
> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  update copyright years

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/240/files
  - new: https://git.openjdk.org/jtreg/pull/240/files/2d138fe3..688a8fb6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=05
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=240&range=04-05

  Stats: 5 lines in 5 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jtreg/pull/240.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/240/head:pull/240

PR: https://git.openjdk.org/jtreg/pull/240

From jvernee at openjdk.org  Thu Feb  6 17:47:25 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 6 Feb 2025 17:47:25 GMT
Subject: Integrated: 7903934: Add support for query strings to the IntelliJ
 plugin
In-Reply-To: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
References: <6uCktMpNVioB4pQojl53y_yDTjB6vJsY5aMt_KgUrno=.bed97ad0-f296-4bbe-bb2c-a001a6c00608@github.com>
Message-ID: <1yQkb_EFblW9lcafY_6kKNu6yJt6gv2pDjSGDRHPtkc=.15561acb-d523-4d81-bee3-6f724022c77f@github.com>

On Fri, 10 Jan 2025 14:50:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch adds support for JTReg query strings to the IntelliJ plugin. Query strings can be used to run individual test methods in JUnit and TestNG tests, and nested test classes (`@Nested`) in JUnit tests. When creating a run configuration from an element in a source file, e.g. by clicking on the little green 'play' button in the margin, the plugin will automatically compute a query string to run that element (if it knows how to).
> 
> One issue I faced when implementing this, is that the IntelliJ type API `PsiType` does not have a way to retrieve the binary name of that type, which is required to run JUnit tests that have parameters. So, I had to manually implement this. You'll see this back in the code.
> 
> I've tested this by creating and running a variety of configurations for different test methods, accepting different parameter types, as well as running `@Nested` test classes.
> 
> Here is a picture of what the new configuration UI looks like:
> 
> ![JTReg Configuration UI](https://github.com/user-attachments/assets/4d2ebe45-74ad-4c27-8a91-101238fc6663)
> 
> The 'Query string' field can only be used in combination with the `File` field, and is disabled otherwise.

This pull request has now been integrated.

Changeset: a3a514cc
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/a3a514cc46c3fe17a2d0969878f0b630e9825c60
Stats:     173 lines in 8 files changed: 138 ins; 9 del; 26 mod

7903934: Add support for query strings to the IntelliJ plugin

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jtreg/pull/240

From duke at openjdk.org  Thu Feb 13 16:51:23 2025
From: duke at openjdk.org (andrlos)
Date: Thu, 13 Feb 2025 16:51:23 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <ts-j8xJf1nIuxc7TPq43byL3C3qOKc4NA3SqrhUPasY=.0b915b11-4660-49ce-bd58-33d16a3d3efa@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
 <uA9y4ZKCN_-Rsri91_WEPdahbaZOPe6W-fn5YzhP7QA=.d1764c3f-eab1-4689-b0e5-22d0ead28a18@github.com>
 <8Vqx8LlIfN9WFhOFOpF7v1dAul4balD5EdGktzip9hA=.f6a673f6-0089-41ec-8241-8cc5f01bcfb5@github.com>
 <ts-j8xJf1nIuxc7TPq43byL3C3qOKc4NA3SqrhUPasY=.0b915b11-4660-49ce-bd58-33d16a3d3efa@github.com>
Message-ID: <Fsb6jPsaxSuYaCr_Hq_uBR9eDEt8HS4-BlvgOhIpsK8=.45c6605e-a130-42ae-a1cb-a83d2763a6f3@github.com>

On Tue, 12 Nov 2024 09:39:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> @sormuras 	feast your eyes on the code below :D
>> 
>> 
>> public class CrashOnlyStatusTransformer implements StatusTransformer {
>>         @Override
>>         public Status transform(Status originalStatus, TestDescription td) {
>>             Status newStatus = originalStatus;
>>             if(originalStatus.getType() == Status.FAILED && ! this.didCrash(td)){
>>                 newStatus = new Status(Status.PASSED, "Just a regular failure.");
>>             }
>>             return newStatus;
>>         }
>> 
>>         private boolean didCrash(TestDescription td){
>>             Pattern pattern = Pattern.compile("^hs_err_pid(\\d+)\.log");
>>             List<String> hs_errs = Arrays.stream(td.getDir().list()).filter(pattern.asPredicate()).collect(Collectors.toList());
>>             return !hs_errs.isEmpty();
>>     }
>> }
>> 
>> 
>> this is an approach that we use for crashtesting with debug jdk builds to separate crashes from regular failures
>
> Hello @andrlos, looking at that code you pasted:
> 
> if(originalStatus.getType() == Status.FAILED && ! this.didCrash(td)){
>     newStatus = new Status(Status.PASSED, "Just a regular failure.");
> }
> 
> It looks odd to be marking a failed test as successful. Furthermore, doesn't a crashed JVM result in test status to be `Status.ERROR`?

@jaikiran @sormuras I believe that I answered all your questions and addressed all your comments and currently I am still waiting for a constructive discussion to take place.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2657191330

From cstein at openjdk.org  Thu Feb 13 17:01:27 2025
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 13 Feb 2025 17:01:27 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
Message-ID: <b0Fq6gDCRcurjhXFzQ6vq2KTY_RsurFB9MJxQmy2wS8=.c4bed3b9-8731-4dff-bfdd-ef9496852bd0@github.com>

On Wed, 6 Nov 2024 01:45:22 GMT, andrlos <duke at openjdk.org> wrote:

> provides SPI for enabling external status transformations of failed tests
> 
> this is a continuation of efforts after https://github.com/openjdk/jtharness/pull/59 
> 
> Requires newest jtharness build (not even tagged yet) that includes above mentioned change to be compiled succesfully
> 
> The main idea is to provide a unified StatusTransformer interface, that can be externally implemented by users and added to a classpath in a separate jar to allow modifications of test execution status based on some elementary analysis. This can be easily used for crashtesting (filtering out only tests with jvm crashes).

With jtreg 7.5.1 being released the other day and soon to be made default in JDK mainline, I will pick up the thread here soon again. Sorry for the delay.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2657216478

From jpai at openjdk.org  Thu Feb 13 17:01:27 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 13 Feb 2025 17:01:27 GMT
Subject: RFR: 7903519 : jtreg/jtharness is missing features for basic crash
 testing
In-Reply-To: <Fsb6jPsaxSuYaCr_Hq_uBR9eDEt8HS4-BlvgOhIpsK8=.45c6605e-a130-42ae-a1cb-a83d2763a6f3@github.com>
References: <1k_V7Eg7B_QW6-WNSNhWWezgOgfLFLnS5zK85TfTiZ0=.b616aac4-079f-4023-adb6-7e4542c7d856@github.com>
 <uA9y4ZKCN_-Rsri91_WEPdahbaZOPe6W-fn5YzhP7QA=.d1764c3f-eab1-4689-b0e5-22d0ead28a18@github.com>
 <8Vqx8LlIfN9WFhOFOpF7v1dAul4balD5EdGktzip9hA=.f6a673f6-0089-41ec-8241-8cc5f01bcfb5@github.com>
 <ts-j8xJf1nIuxc7TPq43byL3C3qOKc4NA3SqrhUPasY=.0b915b11-4660-49ce-bd58-33d16a3d3efa@github.com>
 <Fsb6jPsaxSuYaCr_Hq_uBR9eDEt8HS4-BlvgOhIpsK8=.45c6605e-a130-42ae-a1cb-a83d2763a6f3@github.com>
Message-ID: <p7pwOZ6RK4O3rBJJ7cTl7TdojhVHvSO0eY7VQcviVkc=.9be748e9-7fdd-4528-a77c-e16e064ba990@github.com>

On Thu, 13 Feb 2025 16:49:00 GMT, andrlos <duke at openjdk.org> wrote:

>> Hello @andrlos, looking at that code you pasted:
>> 
>> if(originalStatus.getType() == Status.FAILED && ! this.didCrash(td)){
>>     newStatus = new Status(Status.PASSED, "Just a regular failure.");
>> }
>> 
>> It looks odd to be marking a failed test as successful. Furthermore, doesn't a crashed JVM result in test status to be `Status.ERROR`?
>
> @jaikiran @sormuras I believe that I answered all your questions and addressed all your comments and currently I am still waiting for a constructive discussion to take place.

Hello @andrlos, sorry to keep you waiting. I don't have a strong opinion or objection to this change. At the same time, I don't have enough knowledge of this code to approve this change. So other than asking some basic questions (which I did), I don't feel qualified enough to officially review this proposed enhancement.

-------------

PR Comment: https://git.openjdk.org/jtreg/pull/235#issuecomment-2657217955

From cstein at openjdk.org  Mon Feb 24 08:24:39 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Feb 2025 08:24:39 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
Message-ID: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>

Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.

Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.

Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory

In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:


    -retain | -retain:<pass,fail,error,all,file-pattern>,...
                    Specify files to be retained after each test completes
                    executing. If -retain is not specified, only the files from
                    the last test executed will be retained. If -retain is
                    specified with no argument, all files will be retained.
                    Otherwise, the files may be described by one or more of the
                    following values:
        none            Do not retain any of the files generated by each test
        pass            Retain files generated by tests that pass
        fail            Retain files generated by tests that fail
        error           Retain files generated by tests that caused an error
        all             Retain all files generated by each test
        file-pattern    Retain files that match a specific filename. The name
                        may contain '*' to match any sequence of characters. For
                        example, result.* or *.err.

-------------

Commit messages:
 - 7903953: Use scratch directory for JUnit's TempDir annotation

Changes: https://git.openjdk.org/jtreg/pull/248/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=248&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903953
  Stats: 76 lines in 3 files changed: 74 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/248.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/248/head:pull/248

PR: https://git.openjdk.org/jtreg/pull/248

From jpai at openjdk.org  Mon Feb 24 09:42:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 24 Feb 2025 09:42:07 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
In-Reply-To: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
Message-ID: <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>

On Mon, 24 Feb 2025 08:20:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
> 
> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
> 
> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
> 
> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
> 
> 
>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>                     Specify files to be retained after each test completes
>                     executing. If -retain is not specified, only the files from
>                     the last test executed will be retained. If -retain is
>                     specified with no argument, all files will be retained.
>                     Otherwise, the files may be described by one or more of the
>                     following values:
>         none            Do not retain any of the files generated by each test
>         pass            Retain files generated by tests that pass
>         fail            Retain files generated by tests that fail
>         error           Retain files generated by tests that caused an error
>         all             Retain all files generated by each test
>         file-pattern    Retain files that match a specific filename. The name
>                         may contain '*' to match any sequence of characters. For
>                         example, result.* or *.err.

test/junitTrace/JupiterTempDir.java line 39:

> 37: class JupiterTempDir {
> 38:     @Test
> 39:     @EnabledIfSystemProperty(named = "test.name", matches = "JupiterTempDir.java")

Hello Christian, why is this needed in this test?

test/junitTrace/JupiterTempDir.java line 44:

> 42:         var expected = currentWorkingDirectory.toAbsolutePath().toString();
> 43:         var actual = temporary.getParent().toAbsolutePath().toString();
> 44:         Assertions.assertEquals(expected, actual, "Unexpected root for temporary files");

Would `Files.isSameFile(currentWorkingDirectory, temporary.getParent())` be more appropriate here?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1967288708
PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1967290426

From cstein at openjdk.org  Mon Feb 24 11:27:09 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Feb 2025 11:27:09 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
In-Reply-To: <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
 <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>
Message-ID: <OhXDhShEBgtR3-duWrcUJXS0esFy6QyYBAtm60BhihA=.69e60e9e-d85e-4cdc-ab84-0ab801f51b56@github.com>

On Mon, 24 Feb 2025 09:38:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
>> 
>> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
>> 
>> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
>> 
>> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
>> 
>> 
>>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>>                     Specify files to be retained after each test completes
>>                     executing. If -retain is not specified, only the files from
>>                     the last test executed will be retained. If -retain is
>>                     specified with no argument, all files will be retained.
>>                     Otherwise, the files may be described by one or more of the
>>                     following values:
>>         none            Do not retain any of the files generated by each test
>>         pass            Retain files generated by tests that pass
>>         fail            Retain files generated by tests that fail
>>         error           Retain files generated by tests that caused an error
>>         all             Retain all files generated by each test
>>         file-pattern    Retain files that match a specific filename. The name
>>                         may contain '*' to match any sequence of characters. For
>>                         example, result.* or *.err.
>
> test/junitTrace/JupiterTempDir.java line 39:
> 
>> 37: class JupiterTempDir {
>> 38:     @Test
>> 39:     @EnabledIfSystemProperty(named = "test.name", matches = "JupiterTempDir.java")
> 
> Hello Christian, why is this needed in this test?

The assertion(s) in the test only make sense, when `jtreg` runs the test via its `JUnitRunner`. The `test.name` system property is an indicator that `jtreg` runs the test, I could switch to another one documented here: https://openjdk.org/jtreg/tag-spec.html#testvars

> test/junitTrace/JupiterTempDir.java line 44:
> 
>> 42:         var expected = currentWorkingDirectory.toAbsolutePath().toString();
>> 43:         var actual = temporary.getParent().toAbsolutePath().toString();
>> 44:         Assertions.assertEquals(expected, actual, "Unexpected root for temporary files");
> 
> Would `Files.isSameFile(currentWorkingDirectory, temporary.getParent())` be more appropriate here?

Not sure if this would hold true for every case, especially for some fancy (sym-)linked directories?

I think the `String`-based comparison is good-enough here, and has a nice side-effect producing a human-readable error messages when the assertion fails.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1967454480
PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1967460618

From cstein at openjdk.org  Mon Feb 24 11:31:10 2025
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 24 Feb 2025 11:31:10 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
In-Reply-To: <OhXDhShEBgtR3-duWrcUJXS0esFy6QyYBAtm60BhihA=.69e60e9e-d85e-4cdc-ab84-0ab801f51b56@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
 <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>
 <OhXDhShEBgtR3-duWrcUJXS0esFy6QyYBAtm60BhihA=.69e60e9e-d85e-4cdc-ab84-0ab801f51b56@github.com>
Message-ID: <mmUP1lID-DI-fmkBmG8tHfIsUtolBEbMx2RKbCO3kII=.787b2d39-20cc-450e-ac44-9c04507ad83d@github.com>

On Mon, 24 Feb 2025 11:22:22 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> test/junitTrace/JupiterTempDir.java line 39:
>> 
>>> 37: class JupiterTempDir {
>>> 38:     @Test
>>> 39:     @EnabledIfSystemProperty(named = "test.name", matches = "JupiterTempDir.java")
>> 
>> Hello Christian, why is this needed in this test?
>
> The assertion(s) in the test only make sense, when `jtreg` runs the test via its `JUnitRunner`. The `test.name` system property is an indicator that `jtreg` runs the test, I could switch to another one documented here: https://openjdk.org/jtreg/tag-spec.html#testvars

Perhaps it would be better to replace this non-obvious declarative guard with a programmatic `Assumptions....` statement within the test method. ?

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1967465490

From cstein at openjdk.org  Tue Feb 25 07:26:52 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Feb 2025 07:26:52 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
 [v2]
In-Reply-To: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
Message-ID: <09wAuI2tTLvApmNzmSLXas7E95TWsWWJbVgQjrGlsOc=.8b2ed3cc-becb-4940-a94b-3b1974cfc4d6@github.com>

> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
> 
> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
> 
> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
> 
> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
> 
> 
>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>                     Specify files to be retained after each test completes
>                     executing. If -retain is not specified, only the files from
>                     the last test executed will be retained. If -retain is
>                     specified with no argument, all files will be retained.
>                     Otherwise, the files may be described by one or more of the
>                     following values:
>         none            Do not retain any of the files generated by each test
>         pass            Retain files generated by tests that pass
>         fail            Retain files generated by tests that fail
>         error           Retain files generated by tests that caused an error
>         all             Retain all files generated by each test
>         file-pattern    Retain files that match a specific filename. The name
>                         may contain '*' to match any sequence of characters. For
>                         example, result.* or *.err.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Tidy up test logic

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/248/files
  - new: https://git.openjdk.org/jtreg/pull/248/files/f19a5e9e..296bb50e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=248&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=248&range=00-01

  Stats: 13 lines in 1 file changed: 5 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jtreg/pull/248.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/248/head:pull/248

PR: https://git.openjdk.org/jtreg/pull/248

From jpai at openjdk.org  Tue Feb 25 07:31:04 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Feb 2025 07:31:04 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
 [v2]
In-Reply-To: <mmUP1lID-DI-fmkBmG8tHfIsUtolBEbMx2RKbCO3kII=.787b2d39-20cc-450e-ac44-9c04507ad83d@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
 <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>
 <OhXDhShEBgtR3-duWrcUJXS0esFy6QyYBAtm60BhihA=.69e60e9e-d85e-4cdc-ab84-0ab801f51b56@github.com>
 <mmUP1lID-DI-fmkBmG8tHfIsUtolBEbMx2RKbCO3kII=.787b2d39-20cc-450e-ac44-9c04507ad83d@github.com>
Message-ID: <YYocZXwtry7E8X5M-uF986dBi6j-iYy3gMeXZ0ycXPQ=.5aacc64b-b511-412d-a588-45d0b3144b08@github.com>

On Mon, 24 Feb 2025 11:28:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> The assertion(s) in the test only make sense, when `jtreg` runs the test via its `JUnitRunner`. The `test.name` system property is an indicator that `jtreg` runs the test, I could switch to another one documented here: https://openjdk.org/jtreg/tag-spec.html#testvars
>
> Perhaps it would be better to replace this non-obvious declarative guard with a programmatic `Assumptions....` statement within the test method. ?

> The assertion(s) in the test only make sense, when jtreg runs the test via its JUnitRunner.

Since this is a self test in the jtreg project, would it be the case that a test marked as `@run junit` will always be run by the `JUnitRunner`? So even the assumption I think is probably isn't needed.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1969125262

From cstein at openjdk.org  Tue Feb 25 07:48:06 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Feb 2025 07:48:06 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
 [v2]
In-Reply-To: <YYocZXwtry7E8X5M-uF986dBi6j-iYy3gMeXZ0ycXPQ=.5aacc64b-b511-412d-a588-45d0b3144b08@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
 <_hUFbP7V7jnoyXT33LOHPfKKRfiTv8BFbbjqpp_GmbE=.a9864399-2b57-40db-a2fb-5257d0ec3582@github.com>
 <OhXDhShEBgtR3-duWrcUJXS0esFy6QyYBAtm60BhihA=.69e60e9e-d85e-4cdc-ab84-0ab801f51b56@github.com>
 <mmUP1lID-DI-fmkBmG8tHfIsUtolBEbMx2RKbCO3kII=.787b2d39-20cc-450e-ac44-9c04507ad83d@github.com>
 <YYocZXwtry7E8X5M-uF986dBi6j-iYy3gMeXZ0ycXPQ=.5aacc64b-b511-412d-a588-45d0b3144b08@github.com>
Message-ID: <_QD-Yatt6YKKcb3akbnCUhbodZTF3Sgy9B1yZp2aKIk=.5b09ef24-7721-4166-a624-d7a7c689d221@github.com>

On Tue, 25 Feb 2025 07:28:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Perhaps it would be better to replace this non-obvious declarative guard with a programmatic `Assumptions....` statement within the test method. ?
>
>> The assertion(s) in the test only make sense, when jtreg runs the test via its JUnitRunner.
> 
> Since this is a self test in the jtreg project, would it be the case that a test marked as `@run junit` will always be run by the `JUnitRunner`? So even the assumption I think is probably isn't needed.

When running this self-test without jtreg in play, for example via a direct launch within an IDE(A), it would fail hard. With the assumption in place, developers see:


org.opentest4j.TestAbortedException: Assumption failed: jtreg not running

	at org.junit.jupiter.api.Assumptions.throwAssumptionFailed(Assumptions.java:316)
	at org.junit.jupiter.api.Assumptions.assumeTrue(Assumptions.java:115)
	at JupiterTempDir.currentWorkingDirectoryIsParentOfTemporary(JupiterTempDir.java:44)


Adding a comment, as suggested in another channel, will help future folk though.

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/248#discussion_r1969159540

From cstein at openjdk.org  Tue Feb 25 07:55:44 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Feb 2025 07:55:44 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
 [v3]
In-Reply-To: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
Message-ID: <A2YaJbHIosgYPCQ6m5c6j2cItxLMa5a3Mel6mmxjs5I=.dd5f4804-d94f-4982-8e84-9e54f68408aa@github.com>

> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
> 
> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
> 
> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
> 
> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
> 
> 
>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>                     Specify files to be retained after each test completes
>                     executing. If -retain is not specified, only the files from
>                     the last test executed will be retained. If -retain is
>                     specified with no argument, all files will be retained.
>                     Otherwise, the files may be described by one or more of the
>                     following values:
>         none            Do not retain any of the files generated by each test
>         pass            Retain files generated by tests that pass
>         fail            Retain files generated by tests that fail
>         error           Retain files generated by tests that caused an error
>         all             Retain all files generated by each test
>         file-pattern    Retain files that match a specific filename. The name
>                         may contain '*' to match any sequence of characters. For
>                         example, result.* or *.err.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Add comment

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/248/files
  - new: https://git.openjdk.org/jtreg/pull/248/files/296bb50e..fcbb24de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=248&range=02
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=248&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/248.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/248/head:pull/248

PR: https://git.openjdk.org/jtreg/pull/248

From jpai at openjdk.org  Tue Feb 25 07:59:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 25 Feb 2025 07:59:09 GMT
Subject: RFR: 7903953: Use scratch directory for JUnit's TempDir annotation
 [v3]
In-Reply-To: <A2YaJbHIosgYPCQ6m5c6j2cItxLMa5a3Mel6mmxjs5I=.dd5f4804-d94f-4982-8e84-9e54f68408aa@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
 <A2YaJbHIosgYPCQ6m5c6j2cItxLMa5a3Mel6mmxjs5I=.dd5f4804-d94f-4982-8e84-9e54f68408aa@github.com>
Message-ID: <BuEVFX_CwmJLOaGdEkklk21vGfHC0N5DBEmrbJ8a1k8=.367e2e9e-81ec-48be-8e17-33eee4450b94@github.com>

On Tue, 25 Feb 2025 07:55:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
>> 
>> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
>> 
>> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
>> 
>> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
>> 
>> 
>>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>>                     Specify files to be retained after each test completes
>>                     executing. If -retain is not specified, only the files from
>>                     the last test executed will be retained. If -retain is
>>                     specified with no argument, all files will be retained.
>>                     Otherwise, the files may be described by one or more of the
>>                     following values:
>>         none            Do not retain any of the files generated by each test
>>         pass            Retain files generated by tests that pass
>>         fail            Retain files generated by tests that fail
>>         error           Retain files generated by tests that caused an error
>>         all             Retain all files generated by each test
>>         file-pattern    Retain files that match a specific filename. The name
>>                         may contain '*' to match any sequence of characters. For
>>                         example, result.* or *.err.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Thank you Christian for the updates. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jtreg/pull/248#pullrequestreview-2639943133

From cstein at openjdk.org  Tue Feb 25 08:10:08 2025
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Feb 2025 08:10:08 GMT
Subject: Integrated: 7903953: Use scratch directory for JUnit's TempDir
 annotation
In-Reply-To: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
References: <KrNKc8YpMjNgPFjkItCWc1h94bqfLX1Zp80tzPjNby8=.b53d259b-4e22-4f1b-8ec3-28c746620086@github.com>
Message-ID: <aFAMZbkgbBPOVxfqf8qBybuVTNLZwZcEOD4mAi32Ekk=.4d806a69-b1ec-42f0-a090-fd2dbf73b2bd@github.com>

On Mon, 24 Feb 2025 08:20:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to use `jtreg`'s scratch directory for JUnit's `@TempDir` annotation.
> 
> Prior to this change, the standard implementation of JUnit Jupiter using the system default temporary directory is active, effectively decoupling the location of "interesting on failure" files from `jtreg`:
>> When `jtreg` executes a test, the current directory for the test is set to a scratch directory so that the test can easily write any temporary files.
> 
> Find more details about `jtreg`'s scratch directory at https://openjdk.org/jtreg/faq.html#scratch-directory
> 
> In addition to use the current working directory for `@TempDir` annotated paths, this change also switches off JUnit's built-in cleanup of temporary files - leaving it to `jtreg` to care about it, see for example the help message for  the `-retain` command-line option:
> 
> 
>     -retain | -retain:<pass,fail,error,all,file-pattern>,...
>                     Specify files to be retained after each test completes
>                     executing. If -retain is not specified, only the files from
>                     the last test executed will be retained. If -retain is
>                     specified with no argument, all files will be retained.
>                     Otherwise, the files may be described by one or more of the
>                     following values:
>         none            Do not retain any of the files generated by each test
>         pass            Retain files generated by tests that pass
>         fail            Retain files generated by tests that fail
>         error           Retain files generated by tests that caused an error
>         all             Retain all files generated by each test
>         file-pattern    Retain files that match a specific filename. The name
>                         may contain '*' to match any sequence of characters. For
>                         example, result.* or *.err.

This pull request has now been integrated.

Changeset: 759946de
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jtreg/commit/759946dedbafa423552851ecb98bc3bb8dcf30ec
Stats:     81 lines in 3 files changed: 79 ins; 0 del; 2 mod

7903953: Use scratch directory for JUnit's TempDir annotation

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jtreg/pull/248

From cstein at openjdk.org  Fri Feb 28 10:24:48 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 28 Feb 2025 10:24:48 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module
Message-ID: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>

Please review this change to support compilation of `.jasm` in patched modules.

Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

-------------

Commit messages:
 - 7903955: jtreg doesn't support .jasm in patch module

Changes: https://git.openjdk.org/jtreg/pull/249/files
  Webrev: https://webrevs.openjdk.org/?repo=jtreg&pr=249&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903955
  Stats: 50 lines in 4 files changed: 34 ins; 14 del; 2 mod
  Patch: https://git.openjdk.org/jtreg/pull/249.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/249/head:pull/249

PR: https://git.openjdk.org/jtreg/pull/249

From dlong at openjdk.org  Fri Feb 28 19:31:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 28 Feb 2025 19:31:08 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module
In-Reply-To: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
Message-ID: <zN4I1OekFnbP2jyRiAMnmvd1nM4ZmVfoBznW5uNQB9s=.e356f42c-0227-4efe-9620-a7b51f6e47af@github.com>

On Fri, 28 Feb 2025 10:20:24 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change to support compilation of `.jasm` in patched modules.
> 
> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java line 213:

> 211:             if (currArg.endsWith(".java")) {
> 212:                 foundJavaFile = true;
> 213:             } else if (currArg.endsWith(".jasm") || currArg.endsWith("jcod")) {

Suggestion:

            } else if (currArg.endsWith(".jasm") || currArg.endsWith(".jcod")) {

-------------

PR Review Comment: https://git.openjdk.org/jtreg/pull/249#discussion_r1975916447

From cstein at openjdk.org  Fri Feb 28 22:01:19 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 28 Feb 2025 22:01:19 GMT
Subject: RFR: 7903955: jtreg doesn't support .jasm in patch module [v2]
In-Reply-To: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
References: <LOQ9GRKkmOzsYtXXPNWUIJsOivIT599o_SgHS91Wg1I=.b24ceb26-ef90-422b-ae05-9a4d08f0b92e@github.com>
Message-ID: <r43BhH65dZUu83fBCcSuenFghekesmtNeeC0GS68fJ0=.0c6d86f7-7946-40b4-b6ce-8fff0218c1b2@github.com>

> Please review this change to support compilation of `.jasm` in patched modules.
> 
> Prior to this commit an extra check for `module != null` was the only difference when treating `.java` source files and JASM-related files. With that check removed, the handling of both types of source files could be merged.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update src/share/classes/com/sun/javatest/regtest/exec/CompileAction.java
  
  Co-authored-by: Dean Long <17332032+dean-long at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jtreg/pull/249/files
  - new: https://git.openjdk.org/jtreg/pull/249/files/09a7f1f8..a97f575c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jtreg&pr=249&range=01
 - incr: https://webrevs.openjdk.org/?repo=jtreg&pr=249&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jtreg/pull/249.diff
  Fetch: git fetch https://git.openjdk.org/jtreg.git pull/249/head:pull/249

PR: https://git.openjdk.org/jtreg/pull/249