Get rid of org.eclipse.update.configurator

[laeubi]

The bundle org.eclipse.update.configurator only contains deprecated code and the only evidence that it is actually used anywhere I found in PDE that says:

if (bundles.get("org.eclipse.update.configurator") != null) { //$NON-NLS-1$
	// this argument is required as long as we support old target platforms containing o.e.update.configurator
	// otherwise both simpleconfigurator and update.configurator will try to install bundles, slowing down launches.
	properties.setProperty("org.eclipse.update.reconcile", "false"); //$NON-NLS-1$ //$NON-NLS-2$
}

This is from 2020 and the commit says this is needed to disable it. It therefore looks like this functionally is actually not used/needed/wanted anywhere, but the bundle is for example still included in org.eclipse.rcp feature and some launch configs.

Sadly this even seem to slowdown Eclipse starts see

• ConfigurationActivator should lazy load the PlatformConfiguration #1572

I'm currently working on this to lower the impact, but on the long run it seems better to deprecate the whole bundle and finally remove it completely from the platform.

[laeubi]

Currently the whole purpose seem to be that is provides the service IBundleGroupProvider this then needs to be migrated, this currently also not working very well from a IDE launched product as only deployed features (aka bundle groups) are detected at all.

[Phillipus]

If org.eclipse.update.configurator is removed our RCP product will no longer support additional plug-ins as it relies on it for the dropins folder. We use the dropins folder to add additional plugins. I know of another RCP product that also relies on the dropins folder (also the Eclipse IDE currently supports the dropins folder).

If I remove it:

!ENTRY org.eclipse.equinox.p2.engine 4 4 2024-12-15 09:35:42.259
!MESSAGE An error occurred while installing the items
!SUBENTRY 1 org.eclipse.equinox.p2.engine 4 0 2024-12-15 09:35:42.259
!MESSAGE session context was:(profile=DefaultProfile, phase=org.eclipse.equinox.internal.p2.engine.phases.Install, operand=null --> [R]org.eclipse.update.configurator 3.5.400.v20240416-0654, action=org.eclipse.equinox.internal.p2.touchpoint.eclipse.actions.InstallBundleAction).
!SUBENTRY 1 org.eclipse.equinox.p2.touchpoint.eclipse 4 0 2024-12-15 09:35:42.259
!MESSAGE The artifact file for osgi.bundle,org.eclipse.update.configurator,3.5.400.v20240416-0654 was not found.

And see https://eclipse.dev/equinox/documents/quickstart-framework.php

[laeubi]

Dropins folder is provided by P2, so we probably need adjustments there, but I can't find how it is used anywhere there

https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins
https://github.com/eclipse-equinox/p2/tree/master/bundles/org.eclipse.equinox.p2.reconciler.dropins

beside this, using the drop-ins folder is not really something one would recommend these days as it has several problems.

[Phillipus]

beside this, using the drop-ins folder is not really something one would recommend these days as it has several problems.

As I said:

If org.eclipse.update.configurator is removed our RCP product will no longer support additional plug-ins as it relies on it for the dropins folder. We use the dropins folder to add additional plugins. I know of another RCP product that also relies on the dropins folder (also the Eclipse IDE currently supports the dropins folder).

So if you remove it our product will no longer be able to support its eco-system of add-ons. Would you like to explain that to our thousands of users?

[merks]

Yes, we should be sensitive to what real users are doing and this horrible (dropins) thing I expect is quite widely used and would be badly missed...

[laeubi]

So if you remove it our product will no longer be able to support its eco-system of add-ons. Would you like to explain that to our thousands of users?

if all those thousands of users will contribute to eclipse it would of course not be a problem to better support dropins/outdated techniques...

Apart from that this issue is not about getting rid of dropins at all, and if that feature needs adjustments we would need to do that before removing this. I just can't find a single sign it is actually related there e.g. no code from anywhere actually calls into this bundle, so all code still required might simply be migrated to other places as well.

[Phillipus]

Yes, we should be sensitive to what real users are doing and this horrible (dropins) thing I expect is quite widely used and would be badly missed...

Thanks @merks.

Yes, Archi uses it, Modelio uses it and some other products too. I know that the dropins feature has been superseded by Features and Update sites but there are cases where users can't connect to online feature sites and prefer to be provided with a plug-in as a zip file.

We deliver a main product (Archi) and provide plug-ins downloadable as zip files that can be simply unzipped into a dropins folder in the user's home directory. Then, whenever the main product is updated these plug-ins continue to work without having to be installed.

If the org.eclipse.update.configurator could remain for now it would mean that our product could continue. There are several Archi plug-ins out there (some developed by the European Commission) that would no longer work if this went ahead. It would be nice to be given more time to transition to another solution.

I did experiment with packaging plug-ins as local feature bundles but when the main product was updated the feature bundles had to be re-installed. So I'd need more time to investigate.

[laeubi]

I know that the dropins feature has been superseded by Features and Update sites but there are cases where users can't connect to online feature sites and prefer to be provided with a plug-in as a zip file.

P2 support reading update sites from a file location (and even zip files are specifically supported)

[Phillipus]

P2 support reading update sites from a file location (and even zip files are specifically supported)

Yes, and each time the main product is updated they have to be installed again.

One more time:

If the org.eclipse.update.configurator could remain for now it would mean that our product could continue. There are several Archi plug-ins out there (some developed by the European Commission) that would no longer work if this went ahead. It would be nice to be given more time to transition to another solution.

I did experiment with packaging plug-ins as local feature bundles but when the main product was updated the feature bundles had to be re-installed. So I'd need more time to investigate.

[laeubi]

Yes, and each time the main product is updated they have to be installed again.

Then something is badly broken with your product. I update my Eclipse every month and don't need to reinstall everything again. The problem is more that sometimes old installed stuff (e.g. SVN) gets outdated and I explicitly need to uninstall it after an update.

Anyways, there is no immediate "rush" for anything as:

1. Again this is not about remove dropins support at all
2. If (at some unforeseeable time in the future) we decide we no longer need this, there is still a 2 year deprecation period before it is actually removed

So if your product does not call any code from the bundle you are not affected at all, and even then you likely have a few years left to migrate.

[Phillipus]

So if your product does not call any code from the bundle you are not affected at all, and even then you likely have a few years left to migrate.

Thank-you. If dropins support could continue for a while longer that would be helpful.

[Phillipus]

Yes, and each time the main product is updated they have to be installed again.

Then something is badly broken with your product.

I don't want to side-track this issue with my own implementation issues but I would like to ask for help in implementing the installation of plug-ins by using p2's installation of Features. I have this partially working except for when the main product is updated which causes the installed features to be no longer registered.

1. Our base product is installed by the user in one folder.
2. The product's ini file contains the line -Dosgi.configuration.area=user_home/product_name/config so that all configuration files are located outside of the main product installation. This is because the main product folder might be read-only.
3. If I install a feature containing plug-ins using p2 it is installed correctly in user_home/product_name/features, and user_home/product_name/plugins. Also the user_home/product_name/config/org.eclipse.equinox.simpleconfigurator/bundles.info file is updated with entries for all installed plug-ins, including any third-party plug-ins.
4. However, if the user then updates the main product (or uses a different installed version) the versions of the entries in the bundles.info are now out of sync and any additional plug-ins are not registered and have to be removed and re-installed.
5. So it seems that an installed feature is tied to a particular product installation.

If anyone could point me in the right direction to solve this problem it would help in the transition to use feature installatio rather than dropins.

[laeubi]

@Phillipus I think for your setup you should check this help page:

https://help.eclipse.org/latest/topic/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html?cp=2_1_6_7

I assume you want something like scenario #2 or #3 ... I think it makes sense to maybe continue with a discussion about further details and maybe you can share an example to try out. I used multi-user and shared installs in the past, but depending on the actual environment you need to take some special considerations and maybe there are bugs lingering around.

Especially not that section

Setting the Private Configuration Area Location
The default location for a private configuration area is:
<user-home-dir>/.eclipse/<product-id>_<product-version>/configuration

so it sounds to me that at least different products (or multiple installs of the same product) will require an own configuration folder.

[iloveeclipse]

if all those thousands of users will contribute to eclipse it would of course not be a problem to better support dropins/outdated techniques...

We rely on dropins in our product too and we contribute to Eclipse. I don't think dropins are outdated as they solve a very nice use case that can't be solved by p2 installation. In our case we allow optional product extensions deployed by superuser (automatically) to a dropins directory, so regular user of Eclipse don't need to know anything about p2, features, update sites etc. They just use the product extended in unattended way if needed.