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.
The new bundle org.eclipse.core.runtime.bundlegroups replaces it with a provider that reads the feature list from the platform.xml p2 writes at provisioning time, falling back to a scan of the features directory.
Branding comes from the branding bundle's about.ini, description and bundle list from feature.xml on first access, so no plug-in jar is opened at any point.

Besides the startup cost this takes the last consumer off IPlatformConfigurationFactory, so its announced removal becomes a no-op rather than a regression in the About dialog.
With BundleGroupComponent gone nothing reaches the branding reader in org.eclipse.update.configurator any more, so that package and the IBundleGroup half of FeatureEntry are deleted here too instead of being left as a duplicate of what the new bundle carries.
The deprecated IPlatformConfiguration API and its factory stay untouched.

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.
Consumers need no change, 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 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

    51 files   - 3      51 suites   - 3   58m 27s ⏱️ +21s
 4 764 tests  - 3   4 742 ✅  - 3   22 💤 ±0  0 ❌ ±0 
12 183 runs   - 9  12 030 ✅  - 9  153 💤 ±0  0 ❌ ±0 

Results for commit 7bc93b0. ± Comparison against base commit a68c37a.

This pull request removes 3 tests.

org.eclipse.update.internal.configurator.tests.FeatureEntryTests ‑ testLicenseUrl
org.eclipse.update.internal.configurator.tests.SiteEntryTests ‑ testLoadFromDiskDetectsFeaturesWithoutScanningPlugins
org.eclipse.update.internal.configurator.tests.SiteEntryTests ‑ testPluginsAreDetectedOnFirstAccess

♻️ 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.

[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.

Lots of the non-API code can be deleted. I update the PR.