chore: emit LF in MWE2 workflows + Eclipse prefs, regen src-gen (step 1/2)#1352
Draft
joaodinissf wants to merge 2 commits into
Draft
chore: emit LF in MWE2 workflows + Eclipse prefs, regen src-gen (step 1/2)#1352joaodinissf wants to merge 2 commits into
joaodinissf wants to merge 2 commits into
Conversation
Align MWE2-emitted and Eclipse-emitted output with the project's `.gitattributes` (`* text=auto eol=lf`). - 7 .mwe2 files: `lineDelimiter = "\r\n"` → `"\n"` - 1 Eclipse runtime prefs file: `line.separator=\r\n` → `\n` The CRLF requests dated back to the project's Windows-first era and contradicted the later `.gitattributes` LF normalization. Eliminating them removes the source of cross-platform regen drift in `src-gen`. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Re-run all MWE2 workflows (`Mwe2Launcher Ddk.mwe2`) with the new `lineDelimiter = "\n"` configuration from the previous commit. Most of the resulting tree is identical to what was committed (Git's `.gitattributes` LF normalization on commit had hidden the underlying CRLF emission). Visible changes are pre-existing drift between committed `src-gen/` and the current toolchain that the regen surfaces: - 7 `*Activator.java` (src-gen): Xtext upstream template change (`Maps.newHashMapWithExpectedSize` → `new HashMap<>(N)`) - 5 MANIFEST.MF: Import-Package additions reflected by current generator fragments - 2 .genmodel: EMF `complianceLevel` 11 → 17, runtime 2.29 → 2.36 - 4 new .xtend in xtext.test/src/: FormatterTestLanguage support scaffolding that was missing from the committed src-gen After this commit, re-running `Mwe2Launcher Ddk.mwe2` on a clean checkout produces zero `git status` output — the 246-file drift observed before the LF fix is gone at the source. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
joaodinissf
added a commit
that referenced
this pull request
May 20, 2026
Delete `LfNormalizingFileSystemAccess.java` and remove its wrap calls from `CheckGenerator.xtend` and `CheckCfgGenerator.xtend`. The decorator was introduced in PR #1331 as a post-hoc normaliser against CRLF leaks from various emission paths. After: - step 1 of this stack (#1352) — `.mwe2` `lineDelimiter` and `ddk-configuration` runtime prefs both flipped to `\n` - step 2 (#1353) — `line.separator=\n` propagated to every source-bearing bundle's `.settings/org.eclipse.core.runtime.prefs` - the preceding commit on this branch — `KeywordAnalysisHelper` no longer uses `PrintWriter.println()` …every emission path now produces LF natively. The wrapper is no-op work and the conditional `instanceof IFileSystemAccess2` cast it introduced is no longer needed. Closes #1345 — the planned extension of the same wrapper to `Scope` / `Format` / `Export` generators is no longer needed for the same reason. Those generators are already clean of `Strings.newLine()`, `System.lineSeparator()`, and hardcoded `"\r\n"` emission (audited). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
joaodinissf
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Step 1 of a 2-PR stack aligning every layer of dsl-devkit on LF line endings, matching the project's
.gitattributes(* text=auto eol=lf).This PR fixes the MWE2-side emission (the Maven/build-time codegen path) and the Eclipse-side emission via the central
ddk-configuration/.settings/org.eclipse.core.runtime.prefs(which 56 of 59 source-bearing bundles already link via.projectlinkedResources).Why
.gitattributesdeclares LF as the project convention. Three layers historically contradicted it by explicitly requesting CRLF:code.lineDelimitersettings (this PR fixes those)ddk-configuration/.settings/org.eclipse.core.runtime.prefsline.separator(this PR fixes that)LfNormalizingFileSystemAccessdecorator (PR fix: normalize line endings in check generators #1331) — the workaround layer (removed by step 3, chore: remove LfNormalizingFileSystemAccess (step 2/2, closes #1345) #1354)Empirically: running
Mwe2Launcher Ddk.mwe2on a clean checkout of master produced 246 modified files, dominated by CRLF/LF mismatches. After this PR, the same regen produces ~0 modifications.Changes
Commit 1 — config
.mwe2files incom.avaloq.tools.ddk.workflow/:lineDelimiter = "\r\n"→"\n"(CommonXbase + GenerateExport/Expression/Format/FormatterTestLanguage/Scope/Valid; Check and CheckCfg inherit from CommonXbase via@CommonXbase auto-inject)ddk-configuration/.settings/org.eclipse.core.runtime.prefs:line.separator=\r\n→\nCommit 2 — regenerate src-gen
Re-runs all MWE2 workflows with the new LF setting. Most regenerated content is identical to the committed state (Git normalised on commit), but the regen also picks up pre-existing drift between committed
src-gen/and the current toolchain:*Activator.java(src-gen,*.uibundles)Maps.newHashMapWithExpectedSize→new HashMap<>(N))MANIFEST.MF*.genmodelcomplianceLevel11 → 17, runtime 2.29 → 2.36*.xtendinxtext.test/src/These would have been hidden by the CRLF noise if not regenerated. Including them here brings committed src-gen back into alignment with the toolchain.
Verification
mvn clean verify -DskipTests -T 3C -f ./ddk-parent/pom.xmlpasses locally (Mac, JDK 21).Mwe2Launcher Ddk.mwe2on a fresh checkout produces zerogit statusoutput. (Tested in the worktree the regen was made from.)Stack
Originally planned as step 1 of 3. Step 2 (#1353) was closed as redundant — Andrew Lyne correctly pointed out that 56 of 59 source-bearing bundles already link
.settings/org.eclipse.core.runtime.prefstoddk-configuration/via.projectlinkedResources, so this PR's central-file flip already propagates everywhere it matters. The 3 sample.helloworld bundles that don't link are non-load-bearing.Renumbered stack:
KeywordAnalysisHelper.java'sPrintWriter.println()usage; remove theLfNormalizingFileSystemAccessdecorator (PR fix: normalize line endings in check generators #1331); close issue Extend LF line-ending normalization to remaining runtime generators #1345.Test plan
verifyjob passesline-endingsjob passes (confirmsgit ls-files --eolreports LF across the index)Mwe2Launcher Ddk.mwe2from a clean checkout — expect zerogit statusoutput