fix: deterministic LF line endings for generated files

[joaodinissf]

Problem

Generated-file line endings are platform-dependent: Xtext's default ILineSeparatorInformation returns System.getProperty("line.separator"), so any headless generation on Windows (MWE2 workflows, standalone builders, tests, analysis reports) emits CRLF — while the repository's policy is LF (.gitattributes: * text=auto eol=lf). The index stays clean thanks to git's normalization, but the on-disk bytes differ per platform: generated artifacts aren't reproducible, incremental builders see spurious content changes, and non-git consumers of src-gen get platform-dependent files.

Fix

Make LF the deterministic separator for all machine-owned output:

• LfLineSeparatorInformation (new, in the exported com.avaloq.tools.ddk.xtext.formatting package, next to its interface's home): returns "\n". Bound via bindILineSeparatorInformation() in the runtime module of all seven DDK languages (Check, CheckCfg, Export, Expression, Format, Scope, Valid). Xtext's IWhitespaceInformationProvider.Default injects exactly this type and feeds it to the IFilePostProcessor (LineSeparatorHarmonizer, or the trace-preserving TraceAwarePostProcessor for the Xbase-based languages) that post-processes IFileSystemAccess text writes — so headless generation becomes LF. In the IDE, the UI module's preference-based whitespace provider takes precedence for file writes, so workspace behavior is unchanged. Note for downstream products: headless generation of DDK DSLs on Windows now emits LF instead of CRLF — this is the intended behavior change.
• Generation workflows: ModelInference.mwe2/TypeModel.mwe2 gain lineDelimiter = "\n" on their EcoreGenerator components, and GenerateTestLanguage.mwe2/GenerateHelloWorld.mwe2 drop their unconditional lineDelimiter = "\r\n" pins — the last workflows whose output contradicted the checked-out (LF) form of their own committed src-gen.
• KeywordAnalysisHelper: the diagnostic/report writers use an LfPrintWriter (a PrintWriter whose println() terminates with \n) instead of platform-terminated println.
• LfNormalizingFileSystemAccess is removed: it normalized before the FSA, but the post-processor runs afterwards and owned the final bytes all along — so it never achieved its goal, and stringifying the JvmModelGenerator's TreeAppendable destroyed the trace-region identity the trace-aware post-processor relies on. The runtime-module binding replaces it at the actual enforcement point.

Tests

• LineEndingDeterminismTest drives the real headless write path (JavaIoFileSystemAccess + harmonizer) with the LF binding and a "\r\n" control binding, proving the post-processor follows whatever is bound.
• CheckLineSeparatorBindingTest and FormatLineSeparatorBindingTest pin the Guice convention wiring from two of the seven runtime injectors; the remaining five languages declare the identical binding method but have no runtime test harness to assert it in.
• AbstractCheckGenerationTestCase now asserts every generated file is CR-free and injects members into its in-memory FSA so the post-processor chain — and with it the LF binding — is on the exercised path.
• LfPrintWriterTest covers the report writers' terminator.

Verification

• Mechanism verified against the Xtext 2.43 sources: IWhitespaceInformationProvider.Default injects ILineSeparatorInformation, the bound IFilePostProcessor applies it to IFileSystemAccess text writes, and the default being replaced is System.getProperty("line.separator"); on the IDE path PreferenceStoreWhitespaceInformationProvider consults the injected ILineSeparatorInformation only when no resource URI is available.

🤖 Generated with Claude Code