SEZ9 commented on issue #12655:
URL: https://github.com/apache/seatunnel/issues/12655#issuecomment-6050838190
@Rangsh thanks, that plan looks right to me — nothing to add on the approach.
To confirm your three points:
1. Yes, wait for #11545 (or rebase onto it once merged) so the
`connector-lance` tests actually run with the inherited root
`<argLine>${surefire.jvm.args} ${surefire.module.args}</argLine>`. Verifying
the inheritance on the current `dev` branch isn't meaningful since
`surefire.module.args` isn't there yet.
2. Splitting the `connector-lance/pom.xml` change from the `backend.yml`
`SUREFIRE_JVM_ARGS` cleanup is the right order. Please land the pom PR first
and only remove the repeated `--add-opens` flags from the workflow after that
is in.
3. The scan for other local `<argLine>`/`surefire.jvm.args` overrides is a
good safety check before touching `SUREFIRE_JVM_ARGS`.
Concrete asks for when you open the PRs:
- In the pom PR description, include the JDK 17 command you ran
(`-Dsurefire.jvm.args` without the `--add-opens` flags) and confirm the
`connector-lance` unit tests passed with only the root argLine supplying the
module flags.
- Keep the `darwin-aarch64` profiles untouched and call that out explicitly
so reviewers can see only the surefire `<argLine>` override and the `java9+`
profile are being removed.
- Post the result of your override scan (which modules, if any, still define
their own `<argLine>` or `surefire.jvm.args`) here or in the `backend.yml` PR,
so we know the workflow cleanup won't break another module.
On the overlap with #12662: I agree the fix depends on #11545, so the
duplicate can't be verified yet either. Let's sort out the overlap on that PR
thread rather than here; your plan above is the one I'd like to see go forward.
Please link both of your PRs back to this issue when they're up.
<!-- streview-comment:1583 -->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
