Make ParallelFieldGenerationRaceTest fail deterministically via CyclicBarrier

[Copilot]

The race test relied on OS thread scheduling to produce a two-enum write after a three-enum write, causing it to pass occasionally (false negative).

Changes

• Barrier-coordinated writes — override createOutputStream in an anonymous MessageCodeGenerator subclass; install a CyclicBarrier(2) per output-file path (stored in a ConcurrentHashMap). The returned FilterOutputStream calls barrier.await() on the first write(), forcing two threads to be simultaneously mid-write on the same file on every run.
• Separate generator for the golden baseline — the barrier requires two parties, so a single-task run would deadlock. A plain new MessageCodeGenerator() is used exclusively for the three-enum golden source.
• Resilient barrier handling — BrokenBarrierException and TimeoutException are caught so an unexpected odd-writer-count never hangs the test; those threads proceed and still exercise the race.

CyclicBarrier barrier = barriers.computeIfAbsent(
        outputFile.getAbsolutePath(), k -> new CyclicBarrier(2));
return new FilterOutputStream(super.createOutputStream(outputFile)) {
    private boolean awaited = false;

    @Override
    public void write(byte[] b, int off, int len) throws IOException {
        awaitBarrierOnce();   // block until a second thread is also mid-write
        out.write(b, off, len);
    }
    ...
};

With 16 tasks (8 two-enum, 8 three-enum) writing 1000 field files, the barrier guarantees synchronized pairs on every file — the probability of all 1000 files ending with three-enum content becomes negligible, turning a probabilistic race into a near-certain failure.

[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 one dictonary should have minor version 2, the other (withExtraEnum) should have minor version 4.

[Copilot]

Addressed in commit 13e20b8. ParallelFieldGenerationRaceTest#createDictionary(...) now sets FIX minor version to 2 for the base dictionary and 4 for the withExtraEnum dictionary.