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 target is untouched)

• New ddk-target/ddk-ci.target: same 8 repositories, 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.
• com.avaloq.tools.ddk.xtext.test: 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)

	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 (357+ tests across 81 test classes).
4. 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.