Fix race test: parallel tasks must use separate output directories to detect divergence

[Copilot]

testParallelFieldGenerationMatchesSingleThreadedGolden could never fail: all 16 parallel tasks shared the same dictionary and the same output directory, so every writer produced byte-for-byte identical content. A file-write race is undetectable when all writers write the same bytes — the result is always correct regardless of interleaving.

Changes

• createParallelTasks: each task now receives its own output subdirectory (task-0/, task-1/, …) instead of a shared root.
• Test assertion loop: verifies every task's output subdirectory independently against the sequential golden, so any shared-state corruption (bad cache, non-thread-safe transformer, etc.) surfaces as a mismatch on the specific affected task.

// Before — all tasks write to the same parallelOutput; identical bytes hide any race
tasks.add(createTask("race-" + i, dictionary, transformDirectory, outputDirectory));

// After — each task has an isolated output directory
File taskOutput = new File(parallelRoot, "task-" + i);
tasks.add(createTask("race-" + i, dictionary, transformDirectory, taskOutput));

testDeterministicCorruptionWithTwoConcurrentWriters is unchanged — it intentionally forces byte-level interleaving via CoordinatedOutputMessageCodeGenerator to prove that concurrent writes can corrupt a shared file, and always passing is its correct behaviour.

[chrjohn]

@copilot please add logging output how many parallel tasks are used

[Copilot]

@copilot please add logging output how many parallel tasks are used

Implemented in commit fde52ce. MessageCodeGenerator.generate(List<Task>) now logs the parallel worker count and total task count when parallel execution is enabled.

[chrjohn]

@copilot make generator.parallelExecution true by default.

[Copilot]

@copilot make generator.parallelExecution true by default.

Done in commit d9804f4. generator.parallelExecution is now true by default for multi-task generation; setting it to false forces sequential execution.

[chrjohn]

@copilot parallel execution might work when calling main() of the code generator. However, it does not work when using the GenerateMojo. So the mojo needs the information for all possible executions for the various fix versions at once. Currently there are several executions in quickfixj-messages/quickfixj-messages-all/pom.xml

[Copilot]

@copilot parallel execution might work when calling main() of the code generator. However, it does not work when using the GenerateMojo. So the mojo needs the information for all possible executions f...

Implemented in commit 3703f5f. GenerateMojo now accepts a tasks list and invokes generator.generate(List<Task>), and quickfixj-messages-all/pom.xml was switched from multiple generate executions to one aggregated execution containing all FIX-version tasks so parallel generation is applied across versions. No UI changes in this PR.

[chrjohn]

@copilot looking good so far.

1. Please add a log entry when processing of one task starts and print the number of the task and the total number of tasks like ... "Started task for FIX44 (x / y)"
2. and add a log entry when one task finishes and print the number of the task and the total number of tasks like ... "Finished task for FIX44 (x / y)"

[Copilot]

@copilot looking good so far.

1. Please add a log entry when processing of one task starts and print the number of the task and the total number of tasks like ... "Started task for FIX44 (x / y)"
   2....

Implemented in commit 1804050. Added per-task progress logs in MessageCodeGenerator.generate(List<Task>): Started task for <taskName> (x / y) before execution and Finished task for <taskName> (x / y) in a finally block after each task completes (sequential and parallel modes). No UI changes in this PR, so no screenshot applies.

[chrjohn]

@copilot the test ParallelExecutionOptionTest.testParallelExecutionIsEnabledByDefault is flaky. It expects that the tasks always finish in the same order.

Keep the assertions that verify:

• parallel execution actually happened, and
• the “parallel task execution enabled” log was emitted.
• Remove the assertion that requires task-3 to be the last finished task.
• add a weaker assertion that any finish log for all 4 tasks exists.

[Copilot]

@copilot
ParallelFieldGenerationRaceTest: increase number of fields to 1000 and increase number of threads.

Implemented in commit 53358c4. ParallelFieldGenerationRaceTest now uses 1000 fields and increases parallel tasks from 8 to 16 to raise thread pressure. No UI changes were made, so no screenshot applies.

[chrjohn]

@copilot
ParallelFieldGenerationRaceTest: increase number of fields to 1000 and increase number of threads.

Implemented in commit 53358c4. ParallelFieldGenerationRaceTest now uses 1000 fields and increases parallel tasks from 8 to 16 to raise thread pressure. No UI changes were made, so no screenshot applies.

@copilot please change MessageCodeGenerator so that number of parallel threads can be optionally specified and use 16 parallel tasks in ParallelFieldGenerationRaceTest

[Copilot]

@copilot
ParallelFieldGenerationRaceTest: increase number of fields to 1000 and increase number of threads.

...

Implemented in commit 9c8e038. MessageCodeGenerator now supports optional generator.parallelThreads to configure parallel worker count for multi-task generation, and ParallelFieldGenerationRaceTest explicitly uses 16 parallel threads/tasks via that option. No UI changes were made, so no screenshot applies.

[chrjohn]

@copilot
Please add -Xdiags:verbose to javac compiler options so that I can see a verbose description of compile errors.

[Copilot]

@copilot
Please add -Xdiags:verbose to javac compiler options so that I can see a verbose description of compile errors.

Implemented in commit 09795a5. I added -Xdiags:verbose to the parent maven-compiler-plugin configuration (compilerArgs), so javac emits verbose compile diagnostics across modules. No UI changes were made, so no screenshot applies.

[chrjohn]

@copilot please change the CI build script so that it parses the output on compilation error and does a simple "cat" on the reported file(s). E.g. the build output is like this:

Error:  COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
Error:  /home/runner/work/quickfixj/quickfixj/quickfixj-messages/quickfixj-messages-all/target/generated-sources/quickfix/field/Rule80A.java:[61,1] class, interface, or enum expected
Error:  /home/runner/work/quickfixj/quickfixj/quickfixj-messages/quickfixj-messages-all/target/generated-sources/quickfix/field/Rule80A.java:[63,4] class, interface, or enum expected

Then do a "cat" on the reported files into the build log.

[Copilot]

@copilot please change the CI build script so that it parses the output on compilation error and does a simple "cat" on the reported file(s). E.g. the build output is like this:

...

Implemented in commit d08f2a6. I updated .github/workflows/maven.yml so both Linux/macOS and Windows CI steps capture Maven output, detect COMPILATION ERROR, extract reported *.java:[line,col] file paths, and print (cat/Get-Content) each referenced file into the build log before exiting with the original Maven status.