@Roiocam I just checked, the paradox task still can't catch the compiling error, but it does when running it locally.

@mdedetrich @pjfanning @Roiocam
I think this should be the simplest way.
With an explicit TestJDK9 / test as I chatted with @Roiocam on WeChat.
https://github.com/apache/incubator-pekko/actions/runs/7669498804/job/20903555947?pr=1050#step:5:688

I tried to rewrite the plugin which just replaced the Test / unmanagedSourceDirectieries, but it will need to change more code.

clean;docs/test works for me too, I think we need to figure out why validatePullRequest rather than adding a CI check, what do you think? @He-Pin

[info] compiling 2 Scala sources and 2 Java sources to /Users/roiocam/IdeaProject/incubator-pekko/docs/target/scala-2.13/TestJdk9-classes ...
[error] /Users/roiocam/IdeaProject/incubator-pekko/docs/src/test/java-jdk9-only/jdocs/stream/operators/source/AsSubscriber.java:26:1: illegal start of type declaration
[error] public interface AsSubscriber {
[error] ^
[error] one error found
[info] Run completed in 1 minute, 18 seconds.
[info] Total number of tests run: 629
[info] Suites: completed 181, aborted 0
[info] Tests: succeeded 629, failed 0, canceled 0, ignored 6, pending 1
[info] All tests passed.
[error] (docs / TestJdk9 / compileIncremental) Compilation failed
[error] Total time: 349 s (05:49), completed 2024年1月27日 上午2:19:19

@Roiocam Let's me update the pr and check if that works on ci too.

I verified both works @Roiocam

It can now check the error code in Java 9 folder, and for Java 21 I will do in another PR. @mdedetrich @pjfanning

@pjfanning I mean the file is been compiled in the doc. Check the JDK9+ classes generated is not a target of this PR. Why do you always like to block a PR? you can just leave a comment.

@pjfanning I mean the file is been compiled in the doc. Check the JDK9+ classes generated is not a target of this PR. Why do you always like to block a PR? you can just leave a comment.

#1039 isn't even fixed yet - what we really need is to fix #1039 and then come up with a CI check that stops #1039 ever happening again

@pjfanning I'm preparing a PR for #1039, separately.

Motivation:
Fix #1040

I don't understand this PR at all. #1040 relates to #1039. How is this a fix for #1040?

@pjfanning Because you forgot #958

@pjfanning Because you forgot #958

It is the duty of the PR writer to explain their PR. You made no mention of #958 and claimed this is to be a fix for #1040 - which it isn't.

Can you now explain how this change helps with #958?

@pjfanning Now it will check the error. as ↑

@pjfanning @He-Pin

I have created an issue tracker for those build problems: #1052

I think this issue only related to #959

And #1039 has been fixed by #1047