Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions pom.xml
Original file line number Diff line number Diff line change
Expand Up @@ -373,6 +373,9 @@
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>${maven-surefire-plugin.version}</version>
<configuration>
<argLine>-Xmx2048m</argLine>
</configuration>
Comment on lines +376 to +378
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The hardcoded argLine configuration in pluginManagement will conflict with the JDK 17+ profile at lines 462-485. The JDK 17+ profile sets its own argLine with --add-opens flags required for Java 17+. When both are present, only one argLine will take effect (typically the profile's configuration overrides pluginManagement).

This means that either:

  1. JDK 17+ users will lose the -Xmx2048m setting, or
  2. Users on older JDKs will lose the --add-opens flags if the profile logic fails

The recommended solution is to use the @{argLine} placeholder pattern to allow both configurations to be combined. In pluginManagement, use <argLine>-Xmx2048m</argLine>, and in the JDK 17+ profile, use <argLine>@{argLine} --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/java.lang.reflect=ALL-UNNAMED</argLine>. Alternatively, add the memory configuration to the JDK 17+ profile as well.

Suggested change
<configuration>
<argLine>-Xmx2048m</argLine>
</configuration>

Copilot uses AI. Check for mistakes.
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,24 +1,22 @@
{
"scenarioName": "Validate the GET api",
"steps": [
{
"name": "get_user_details",
"url": "/users/octocat",
"method": "GET",
"request": {
"headers" : {
"Content-Type" : "application/json"
}
},
"verify": {
"status": 200,
"headers" : {
"Content-Type" : [ "application/json; charset=utf-8" ]
},
"body": {
"login" : "octocat"
}
}
"scenarioName": "Validate the GET api",
"steps": [
{
"name": "get_user_details",
"url": "/users/octocat",
"method": "GET",
"request": {
"headers": {
"Content-Type": "application/json"
}
]
}
},
"verify": {
"status": 200,
"headers": {
"Content-Type": ["application/json; charset=utf-8"]
},
"rawBody": "{\"login\":\"octocat\"}"
Copy link

Copilot AI Feb 23, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The change from "body" to "rawBody" in this archetype template is inappropriate. The GitHub API /users/octocat endpoint returns valid JSON (application/json), not raw text or binary data. The "rawBody" field should only be used for non-JSON responses like XML, plain text, or binary content.

According to the PR description and linked issue #724, rawBody is intended for "large or non-JSON responses." However, this is a standard JSON response from GitHub's API. All other GitHub API test examples in the codebase (e.g., http-testing-examples/src/test/resources/loadtesting/github_get_api_test_case.json) use "body" with JSON object assertions, not rawBody with escaped JSON strings.

The original code with "body": {"login": "octocat"} is the correct pattern for JSON responses and should be restored.

Suggested change
"rawBody": "{\"login\":\"octocat\"}"
"body": {
"login": "octocat"
}

Copilot uses AI. Check for mistakes.
}
}
]
}