Provide bundle groups without scanning the installation

[vogella]

Fixes #2863

The SDK's only IBundleGroupProvider was BundleGroupComponent in org.eclipse.update.configurator, which built the legacy PlatformConfiguration and opened every plugins/*.jar to read its manifest, on the UI thread during startup. This replaces it with a provider in the new bundle org.eclipse.core.runtime.bundlegroups that reads the feature list from the platform.xml p2 writes at provisioning time, falling back to a scan of the features directory for installations without one. Branding still comes from the branding bundle's about.ini, and description, license and bundle list are parsed from feature.xml on first access, so no plug-in jar is opened at any point.

Besides removing the startup cost, this takes the last consumer off IPlatformConfigurationFactory. After this change nothing outside org.eclipse.update.configurator references the deprecated API, so its announced removal becomes a no-op rather than a regression in the About dialog. The bundle itself and the deprecated API stay untouched until then.

The platform.xml model and parser are copied from the read path of org.eclipse.equinox.internal.p2.update and pruned to what a feature entry needs. Copying rather than depending keeps p2 out of org.eclipse.rcp, which ships without it; PDE set the same precedent with org.eclipse.pde.internal.core.update.configurator. No consumer changes are needed since they all go through Platform.getBundleGroupProviders().

Note for merging: this needs a matching <plugin id="org.eclipse.core.runtime.bundlegroups" version="0.0.0"/> entry in org.eclipse.rcp/feature.xml over in eclipse.platform.releng.aggregator. Until that lands there is no bundle group provider at all, since the old one is removed here.

[vogella]

Something for early next release

[github-actions]

Test Results

    54 files  +   18      54 suites  +18   1h 0m 11s ⏱️ + 17m 38s
 4 759 tests ±    0   4 737 ✅ +   23   22 💤  - 23  0 ❌ ±0 
12 168 runs  +4 056  12 015 ✅ +4 014  153 💤 +42  0 ❌ ±0 

Results for commit 5b5056d. ± Comparison against base commit fd0d61c.

♻️ This comment has been updated with latest results.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 8bbbb19a6c4697b52319feae90855937b227a854 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Mon, 31 Aug 2026 14:02:08 +0000
Subject: [PATCH] Version bump(s) for 4.42 stream


diff --git a/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF b/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
index 6ab76dfa84..43f99afc01 100644
--- a/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
+++ b/runtime/bundles/org.eclipse.e4.core.di/META-INF/MANIFEST.MF
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-SymbolicName: org.eclipse.e4.core.di
-Bundle-Version: 1.9.900.qualifier
+Bundle-Version: 1.9.1000.qualifier
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-Localization: plugin
-- 
2.55.0

Further information are available in Common Build Issues - Missing version increments.

[merks]

Wow, that's a lot of code. I guess it moved from somewhere?

[vogella]

org.eclipse.update.configurator

Yes, most comes from org.eclipse.equinox.internal.p2.update

[merks]

I guess without history. Oh well...

[HeikoKlare]

I see that at least AboutInfo and IniFileReader are identical to those in org.eclipse.update.configurator. Isn't there a chance to move them (and maybe other) instead and have them referenced to avoid duplication?

[vogella]

I see that at least AboutInfo and IniFileReader are identical to those in org.eclipse.update.configurator. Isn't there a chance to move them (and maybe other) instead and have them referenced to avoid duplication?

The whole code in update.configurator can be deleted once this is in and the planned API deletion period for update.configurator has been reached.

[HeikoKlare]

That code is not API, is it? So why not (re)move it right away?

[vogella]

That code is not API, is it? So why not (re)move it right away?

I check tomorrow, IIRC some API marked for deletion was using it.