perf(target): add slim slicer-mode ddk-ci.target as opt-in alternative

[joaodinissf]

Problem

The default ddk.target uses includeMode="planner", which provisions a complete install closure. Cost per Eclipse workspace (and per CI cold start): 325 MB / 861 jars eagerly downloaded, 411 of them source bundles (105 MB). Setting includeSource="false" does not help: PDE's planner path runs its plan-in-source-bundles pass unconditionally (no getIncludeSource() check in P2TargetUtils), so sources are fetched for everything regardless of the flag.

Change (opt-in; the default ddk.target file is untouched)

• New ddk-target/ddk-ci.target: the same repositories as ddk.target, includeMode="slicer", SDK features replaced by runtime features, and every requirement-only bundle listed explicitly. Attached with classifier ddk-ci; select with -Dtarget.platform=ddk-ci.
• Every location uses includeAllPlatforms="true". org.eclipse.jdt.launching.macosx is needed on macOS but carries an osgi.os=macosx filter, and a filtered root is rejected when resolving for Linux or Windows; Tycho requires the same value on all locations, so it applies to the whole file. Other platforms' fragments (SWT is the largest, ~2.6 MB each) become part of the slice; Tycho still wires only the matching ones.
• com.avaloq.tools.ddk.xtext.test (applies to both targets): the surefire runtime required the whole org.eclipse.xtext.sdk feature; replaced with the xtext runtime/ui/xbase features plus the bundles the tests actually use at runtime — including org.eclipse.xtext.xtext.ui, whose EMF resource-factory registration is required to load .xtext grammar resources (its absence was the cause of the first CI run's test failures). Resolvable under both targets.

Every unit in the new file is traceable to a concrete resolution error: the file was grown by an error-driven loop (mvn clean package/verify naming the missing capability each iteration), not copied from anywhere.

Measured (local, macOS aarch64; medians of ≥3 runs where stated; before the switch to includeAllPlatforms="true", which adds the other platforms' fragments)

	default ddk.target	ddk-ci.target
PDE cold workspace provisioning (resolve)	34–47 s	22–27 s
bundle pool	325 MB	~205 MB (−37%)
jars	861	~440 (−49%)
source jars	411	30 (−93%)
Tycho warm validate	~10 s	~10 s (unchanged — warm is not download-bound)

Verification

1. Full mvn clean package green (all modules), under both targets.
2. Tycho-surefire's install-grade runtime assembly green (this stricter resolution caught, and the target now includes, runtime-only needs such as com.jcraft.jsch and the ECF/httpclient5 transport stack).
3. Full mvn clean verify green with zero test failures under BOTH the default target and ddk-ci.target on macOS aarch64 (357+ tests across 81 test classes).
4. Target resolution of ddk-ci.target succeeds for both linux/gtk/x86_64 and macosx/cocoa/aarch64 (platform profile forced locally). Before the includeAllPlatforms change the Linux resolution failed with org.eclipse.jdt.launching.macosx … cannot be installed in this environment because its filter is not applicable. CI does not build this target yet, so no Linux build or test run has used it.
5. Static audit of all 46 dropped binary bundles against the whole repo (manifests, poms, .launch, .product, plugin.xml, code): the only dynamic reference is ddk-configuration/launches/devkit-run.launch, which uses the automatic bundle set (default=true) and therefore adapts; it is not used by CI.

Known trade-offs: a workspace using ddk-ci.target has no source attachments (use the default target for source browsing), and the launched runtime workbench lacks IDE extras (xtend.ide, docs, examples). 30 source jars remain (embedded in the Xtext features' own feature.xml).

CI numbers (added after workflow runs)

verify workflow, ubuntu runner: 10m39s (green run on the current commit) vs recent master runs median ~13m25s (n=8, range 11m49s–18m34s). Caveat: CI currently builds the default target, so this difference is likely cache warmth/runner variance rather than the change itself — the measured provisioning gains (−37% download, −93% source bundles, ~35–40% faster cold resolve) apply to workspace/CI environments that opt into -Dtarget.platform=ddk-ci. Switching CI to the slim target would be a follow-up once the team is comfortable.

---

Assisted by Claude.

[rubenporras]

I also thought about the effect of using slicer on performance. If we go for it, why not do it directly in the current target instead of creating a new one? In the end we want the speed up even more for the target reloads/updates we do locally.

[joaodinissf]

Closing. The slicer does make cold target resolution faster, but not by enough to justify keeping a hand-maintained 179-unit target in sync with every Eclipse, Xtext and Orbit update (roughly every six to eight weeks). As an opt-in file it would rot, since CI never builds it, and it had already drifted from ddk.target. As the default, we would pay that maintenance on every update to save 15 to 20 seconds per cold reload. @rubenporras, that is also my answer to your question: the gain doesn't justify the upkeep, opt-in or default.

🤖 Drafted with Claude Code