Make field-generation race reproducible with deterministic interleaving test

[Copilot]

Field class corruption from concurrent writes to the same output path was hard to reproduce because the existing test was probabilistic and often ended in a valid “last writer wins” file. This PR makes the race reproducible and detectable with deterministic write interleaving.

• Deterministic race reproduction in codegenerator tests

  • Added a two-task race scenario that writes the same field class from different dictionaries with distinct generated content.
  • Introduced a coordinated test output stream that synchronizes both writers (barrier after open/truncate) and enforces a controlled interleaving pattern.

• Minimal production seam for test-controlled output

  • Added a protected output-stream factory hook in MessageCodeGenerator so tests can inject controlled writer behavior without changing generation logic.
  • generateCodeFile(...) now delegates stream creation via createOutputStream(File).

• Stronger corruption assertion

  • The deterministic test compares final output against both valid variants and asserts it is neither, proving mixed/corrupt output rather than normal overwrite behavior.

// MessageCodeGenerator
protected OutputStream createOutputStream(File outputFile) throws FileNotFoundException {
    return new BufferedOutputStream(new FileOutputStream(outputFile));
}

[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.

[chrjohn]

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

[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.