Community
Participate
Working Groups
With the org.eclipse.update.configurator 3.4.100 our application no longer works as the required bundles are no longer installed. The problem does not show up using the update configurator 3.3.400- After an analysis of the changes, I can say that the problem follows modifications for bug 527783. In fact, I tried to locally revert those changes in 3.4.100 an then the bundles were installed as expected. As far as I could understand, although the "p2 explicitly disables update.configurator reconciling which was removed" as stated in the bug 527783 ticket comments, the removed code was executed iff: public static boolean isReconciling() { String reconcile = context.getProperty("org.eclipse.update.reconcile"); //$NON-NLS-1$ return reconcile == null || reconcile.equalsIgnoreCase("true"); //$NON-NLS-1$ } so even in case the "org.eclipse.update.reconcile" property was not set.
(In reply to Davide Ceraso from comment #0) > As far as I could understand, although the "p2 explicitly disables > update.configurator reconciling which was removed" as stated in the bug > 527783 ticket comments, the removed code was executed iff: > > public static boolean isReconciling() { > String reconcile = context.getProperty("org.eclipse.update.reconcile"); > //$NON-NLS-1$ > return reconcile == null || reconcile.equalsIgnoreCase("true"); > //$NON-NLS-1$ > } > > so even in case the "org.eclipse.update.reconcile" property was not set. Davide, thanks for reporting and analyse, can you provide a gerrit patch?
Davide, can you please also provide steps to reproduce or even a small example which shows the problem?
Hi Andrey, I'll try to provide the requested patch. About the repro scenario, we have an eclipse-based web application that uses the config.ini file for the configuration. When we deploy the war file to the tomcat server using org.eclipse.update.configurator v3.4.100 the application fails to starts because it is not able to resolve all the needed dependencies, although the needed plugins are in the plugins folder and they are all correctly configured in the config.ini file. This problem does not show up when we use the org.eclipse.update.configurator v3.3.400 and neither using the v3.4.100 when replacing the ConfigurationActivator and the PlatformConfiguration classes with the ones from the v3.3.400.
I have the same problem. See https://github.com/archimatetool/archi/issues/429 Basically my config.ini is this: eclipse.application=com.archimatetool.editor.app osgi.bundles.defaultStartLevel=4 eclipse.product=com.archimatetool.editor.product osgi.splashPath=platform:/base/plugins/com.archimatetool.editor osgi.bundles=org.eclipse.equinox.common@2:start,org.eclipse.update.configurator@3:start,org.eclipse.equinox.ds@3:start,org.eclipse.core.runtime@start I replaced org.eclipse.update.configurator_3.4.100.v20180821-1913 (comes with Eclipse 3.9) with version org.eclipse.update.configurator_3.3.400.v20160506-0750.jar from Eclipse 3.7 and it fixed the problem of not launching the app. See also https://github.com/diffplug/goomph/issues/69
Hello, any plan that fixing it recently? I am migrating our RCP product to eclipse 4.10 but blocked by this issue. BR Chao
org.eclipse.update is not supported anymore, IIRC correctly it was very long ago deprecated and announced to be removed. You should move to p2 updates, see for example http://www.vogella.com/tutorias/EclipseP2Update/article.html for an tutorial how to use it.
(In reply to Lars Vogel from comment #6) > org.eclipse.update is not supported anymore, IIRC correctly it was very long > ago deprecated and announced to be removed. > > You should move to p2 updates, see for example > http://www.vogella.com/tutorias/EclipseP2Update/article.html for an tutorial > how to use it. Then our RCP application that has used our custom plugin installation for the past 10 years is dead in the water. We don't want to impose the non user-friendly p2 mechanism on our users.
(In reply to Phil Beauvoir from comment #7) > (In reply to Lars Vogel from comment #6) > > org.eclipse.update is not supported anymore, IIRC correctly it was very long > > ago deprecated and announced to be removed. > > > > You should move to p2 updates, see for example > > http://www.vogella.com/tutorias/EclipseP2Update/article.html for an tutorial > > how to use it. > > Then our RCP application that has used our custom plugin installation for > the past 10 years is dead in the water. We don't want to impose the non > user-friendly p2 mechanism on our users. I strongly recommend everyone to start using p2 (thanks Lars for the detailed tutorial) as update.configurator is on it's way out (deprecated almost 10 years ago) and more and more pieces from it will disappear. Is there a reason why people are not using dropins? Similar workflow is achievable that way. See https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins how you can still just drop files there and they will be reconciled but this way from the actual code that still is used by everyone else instead of smth rotting for a decade.
(In reply to Alexander Kurtakov from comment #8) > (In reply to Phil Beauvoir from comment #7) > > (In reply to Lars Vogel from comment #6) > > > org.eclipse.update is not supported anymore, IIRC correctly it was very long > > > ago deprecated and announced to be removed. > > > > > > You should move to p2 updates, see for example > > > http://www.vogella.com/tutorias/EclipseP2Update/article.html for an tutorial > > > how to use it. > > > > Then our RCP application that has used our custom plugin installation for > > the past 10 years is dead in the water. We don't want to impose the non > > user-friendly p2 mechanism on our users. > > I strongly recommend everyone to start using p2 (thanks Lars for the > detailed tutorial) as update.configurator is on it's way out (deprecated > almost 10 years ago) and more and more pieces from it will disappear. > Is there a reason why people are not using dropins? Similar workflow is > achievable that way. See > https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins how you can > still just drop files there and they will be reconciled but this way from > the actual code that still is used by everyone else instead of smth rotting > for a decade. Because apparently dropins is also deprecated. And I spent the last 2 days trying to get it to work. And I can't get it to work. I think this is the last straw for me with Eclipse.
And I find the attitude here worryingly arrogant. There are so many RCP apps out there that rely on this method. If it was deprecated 10 years ago why did we not know.
Dropins is/was the migration path for people from update.configurator to p2 thus was never a recommended path. At least it is still maintainable in comparison to the update.configurator. What is the issue you face with dropins?
(In reply to Alexander Kurtakov from comment #11) > Dropins is/was the migration path for people from update.configurator to p2 > thus was never a recommended path. At least it is still maintainable in > comparison to the update.configurator. > What is the issue you face with dropins? I spent two days of frustrating trial and error with varying targets, 4.7, 4.8, 4.9, product files, outdated online wikis, google search, and other wastes of time to come to find out that even though plugins added to the dropins folder are "discovered" by the system, as seen in the debug window, they simply do not show up.
> We don't want to impose the non user-friendly p2 mechanism on our users. Use P2 API instead, see tutorial.
Furthermore, the amount of bloat of equinox, p2, and ECF plugins needed to even to try and get this to work is ridiculous. All I need to do is put a jar file in the plugins folder.
> > I spent two days of frustrating trial and error with varying targets, 4.7, > 4.8, 4.9, product files, outdated online wikis, google search, and other > wastes of time to come to find out that even though plugins added to the > dropins folder are "discovered" by the system, as seen in the debug window, > they simply do not show up. See, I want to help here but this information is not enough to understand what is going on on your side. FWIW, quick search pointed to https://www.eclipse.org/eclipse/development/readme_eclipse_3.5.html - "New plug-ins can be installed into the system by unzipping them into the plugins directory. However this is not recommended, and the dropins directory should be used for this purpose instead. " If anyone goes through the release notes, planned removals and etc. more will be found. So the first try (I found, there are probably others if someone search more) to move people away from extracting in plugins is the release from 24 June 2009 . We (Eclipse project) do a lot to maintain compatibility, document every removal, give 2 years(at least!!!) of notice before anything is removed and so on. At the end people do not read the docs, notices and etc., no one cares about our recommendations (or even read them) and at the end we are blamed to be arrogant. I don't know what to say about this.
Hello, does P2 have anyway to install all bundles in plugins folder on application startup?
I can't visit http://www.vogella.com/tutorias/EclipseP2Update/article.html, it shows 404 error page. Do we have any document to tell us how to generate the bundles.info based on the built product? We use maven/tycho building products. I find I can add all bundles into the product file, but it's too hard to maintenance every product, cause we need hundreds of bundles in the plugins folder and every product need different bundles and there may be many dependencies missing during configuring the bundles list, cause there are many cascaded dependencies, it's hard to check all of them; and we even need to add some customized parameters to config.ini, but seems product file doesn't support to add parameters to config.ini dynamically during building, so we have to use maven way to generate the config.ini. I thought we could generate the bundles.info based on the features configured in the product file, but it can't be a way for us, cause features may also missing some dependencies. So it's hard for us to use the product file to generate the config.ini and bundles.info, we only have little customized bundle autoStart, what we did was adding them into the osgi.bundles of config.ini, and then let eclipse load all bundles in the plugins folder, it would be better and easier to use if rcp application can generate the bundles.info automatically or load all bundles automatically. Do you have any offical recommanded way to manage them? Thanks in advance. Chao
Correct link: http://www.vogella.com/tutorials/EclipseP2Update/article.html
(In reply to meng chao from comment #16) > Hello, does P2 have anyway to install all bundles in plugins folder on > application startup? P2 has a way to install all plugins in dropins folder. What you need to do is have the RCP as usual (it's contents in TOP_DIR/plugins) and plugins to be resolved on startup put in TOP_DIR/dropins. See https://wiki.eclipse.org/Equinox/p2/Getting_Started#Dropins for details.
Sadly, dropins is not working in 4.8 or 4.9 when generating the RCP app from a product file. I got it to work in 4.7, however. But the same setup does not work in later versions. Even when it "works" the outcome is unsatisfactory. Many ECF bundles are included which are related to file transfer and not needed by the app, a spurious "launcher.exe" is generated, and an unwanted Security tab is now present in Preferences. This whole process is below par for the thousands of users of our RCP app. For an RCP application that simply wants to place a jar file in a plugins folder the whole dropins thing is a mesas. I can only recommend the workaround of copying an older version of org.eclipse.update.configurator as in commet #4.
(In reply to Phil Beauvoir from comment #9) > Because apparently dropins is also deprecated. And I spent the last 2 days > trying to get it to work. And I can't get it to work. I think this is the > last straw for me with Eclipse. (In reply to Alexander Kurtakov from comment #11) > Dropins is/was the migration path for people from update.configurator to p2 > thus was never a recommended path. At least it is still maintainable in > comparison to the update.configurator. > What is the issue you face with dropins? Is dropins deprecated? IMO it is fully supported by P2.
(In reply to Wim Jongman from comment #21) > (In reply to Phil Beauvoir from comment #9) > > Because apparently dropins is also deprecated. And I spent the last 2 days > > trying to get it to work. And I can't get it to work. I think this is the > > last straw for me with Eclipse. > > (In reply to Alexander Kurtakov from comment #11) > > Dropins is/was the migration path for people from update.configurator to p2 > > thus was never a recommended path. At least it is still maintainable in > > comparison to the update.configurator. > > What is the issue you face with dropins? > > Is dropins deprecated? IMO it is fully supported by P2. "There is a fourth approach for integrating p2 into your app: using dropins. But dropins are not recommended, and has been officially deprecated by the p2 team." https://wiki.eclipse.org/Equinox/p2/FAQ Good luck.
