Community
Participate
Working Groups
Eclipse Version: Mars (4.5) Build id: I20150106-0800 Implementing IStartup on an activator (AbstractUIPlugin) plug-in for an RCP app causes this: !ENTRY org.eclipse.ui.workbench 4 2 2015-01-07 12:37:25.991 !MESSAGE Problems occurred when invoking code from plug-in: "org.eclipse.ui.workbench". !STACK 1 org.eclipse.core.runtime.CoreException: Executable extension definition for "class" not found. at org.eclipse.core.internal.registry.ConfigurationElement.throwException(ConfigurationElement.java:62) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:222) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:284) at org.eclipse.ui.internal.EarlyStartupRunnable.getExecutableExtension(EarlyStartupRunnable.java:90) at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:49) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.Workbench$56.run(Workbench.java:2801) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 1 org.eclipse.equinox.registry 4 1 2015-01-07 12:37:25.999 !MESSAGE Executable extension definition for "class" not found. !SUBENTRY 1 org.eclipse.equinox.registry 4 1 2015-01-07 12:37:25.999 !MESSAGE Executable extension definition for "class" not found. !ENTRY Test 4 0 2015-01-07 12:37:26.003 !MESSAGE Unable to execute early startup code for an extension !STACK 1 org.eclipse.core.runtime.CoreException: Executable extension definition for "class" not found. at org.eclipse.core.internal.registry.ConfigurationElement.throwException(ConfigurationElement.java:62) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:222) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:284) at org.eclipse.ui.internal.EarlyStartupRunnable.getExecutableExtension(EarlyStartupRunnable.java:90) at org.eclipse.ui.internal.EarlyStartupRunnable.run(EarlyStartupRunnable.java:49) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.Workbench$56.run(Workbench.java:2801) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) !SUBENTRY 1 org.eclipse.equinox.registry 4 1 2015-01-07 12:37:26.004 !MESSAGE Executable extension definition for "class" not found.
Created attachment 249756 [details] Modified "Hello RCP" application Modified Test Project "Hello RCP". Implements IStartup in Activator class, and added "org.eclipse.ui.startup" extension point to plugin.xml. Run as RCP application from Eclipse 4.5 Mars build. Error is logged to console.
Note - no error is thrown in Eclipse 4.4 and implementing IStartup in this ways is supported.
In the attached example project, it's not necessary to implement IStartup in the Activator class to trigger the exception, only the extension declaration in plugin.xml: <extension point="org.eclipse.ui.startup"> <startup></startup> </extension>
It turns out that if you explicitly set the class that implements IStartup thus: <extension point="org.eclipse.ui.startup"> <startup class="test.Activator"></startup> </extension> then the exception is not thrown. However, the documentation for the extension point states: "Do not specify the plug-in class as the value of the class attribute, or it will be instantiated twice (once by regular plug-in activation, and once by this mechanism)." In Eclipse 4.4 not specifying the plug-in class (Activator in this example) works, and the startup() method is called. Not so in 4.5.
I notice that in Eclipse 4.5 M5a there is now an error reported: "Attribute 'class' of element 'startup' must be defined" However, this conflicts with the documentation for org.eclipse.ui.startup: "Do not specify the plug-in class as the value of the class attribute, or it will be instantiated twice (once by regular plug-in activation, and once by this mechanism)."
Adding Tom to CC, in case related to changes in equinox.registry?
Class attribute became mandatory with the removal of the 2.0 campatibility layer, see Bug 455165 and related. I thought we updated the (schema) documentation, can you point me to the documentation your are looking at?
(In reply to Phil Beauvoir from comment #4) > In Eclipse 4.4 not specifying the plug-in class (Activator in this example) > works, and the startup() method is called. Not so in 4.5. I was using this approach as well (it's still mentioned in the wiki without any pointer to this breaking change). Are there any plans to reinstall support for this behavior or do plugins have to be adjusted with future releases? My workaround for now is to use a separate class as required, get the plugin bundle and start it manually.
Lars, we have to fix this for 4.5. I agree with Konstantin that this was not properly communicated. Even if one reads our removals page [1], one cannot have known that this will affect the extension point. [1] http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/porting/removals.html?cp=2_3_0
(In reply to Dani Megert from comment #9) > Lars, we have to fix this for 4.5. > > I agree with Konstantin that this was not properly communicated. Even if one > reads our removals page [1], one cannot have known that this will affect the > extension point. > > > [1] > http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/porting/ > removals.html?cp=2_3_0 See Bug 394739 for the removal of the 2.0 comp. layer. I think there is nothing to fix here, we enhanced the Javadoc and error messages via Bug 455165 and Bug 457132.
(In reply to Lars Vogel from comment #10) > (In reply to Dani Megert from comment #9) > > Lars, we have to fix this for 4.5. > > > > I agree with Konstantin that this was not properly communicated. Even if one > > reads our removals page [1], one cannot have known that this will affect the > > extension point. > > > > > > [1] > > http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/porting/ > > removals.html?cp=2_3_0 > > See Bug 394739 for the removal of the 2.0 comp. layer. How should one know that this affects the extension point?
(In reply to Dani Megert from comment #11) > > See Bug 394739 for the removal of the 2.0 comp. layer. > > How should one know that this affects the extension point? IIRC the extension point stated that this only works with the comp. layer present. See https://git.eclipse.org/r/#/c/36310/3/bundles/org.eclipse.ui/schema/startup.exsd where I removed this info after we removed the comp. layer.
(In reply to Lars Vogel from comment #12) > (In reply to Dani Megert from comment #11) > > > See Bug 394739 for the removal of the 2.0 comp. layer. > > > > How should one know that this affects the extension point? > > IIRC the extension point stated that this only works with the comp. layer > present. See > https://git.eclipse.org/r/#/c/36310/3/bundles/org.eclipse.ui/schema/startup.exsd > where I removed this info after we removed the comp. layer. That may be, but we cannot expect that our users read all extension point doc and all Java type doc to check whether they might get broken. This needs to be listed in the removals doc. If we can't add code that simply supports the old-style of the extension point, then we have to revert the compat layer for 4.5.
> That may be, but we cannot expect that our users read all extension point > doc and all Java type doc to check whether they might get broken. My personal expectation would have been to read about this change in the plug-in migration guide. From the error message and the Javadoc it is clear what changes one has to apply to conform with the API, but IMHO it would be better to be able to read about it upfront. Plus, currently there is no information available how to mimic the previous behavior, which might be intentional given that lazy activation is recommended and favorable. It took me about 10 minutes to come up with a solution, which fares really quite well compared to the competition. But including a pointer to a wiki entry with the relevant code in the migration guide would be nice and should really ease any pain this change might yield. > This needs to be listed in the removals doc. +1 > If we can't add code that simply supports > the old-style of the extension point, then we have to revert the compat > layer for 4.5. If you don't want to break plugins at all cost, this seems like the easiest solution. Personally, I don't mind to have to perform housekeeping from time to time. It should affect only a minority of plugins anyway. Thanks much for all your work!
(In reply to Dani Megert from comment #13) > That may be, but we cannot expect that our users read all extension point > doc and all Java type doc to check whether they might get broken. This needs > to be listed in the removals doc. I think that is how we define API. IIRC the removal was started in 4.2 (I was not involved in this discussion) so John or Paul might have more info on this. If we can't add code that simply supports > the old-style of the extension point, then we have to revert the compat > layer for 4.5. The removal and / or deprecation of the compatibility resulted in several commits all over the places, I don't think it is realistic or desirable to restore it in M7. But again IIRC the plan was started in 4.2 without my involvement so maybe people like John or Paul can give more input here.
(In reply to Lars Vogel from comment #15) > (In reply to Dani Megert from comment #13) > > That may be, but we cannot expect that our users read all extension point > > doc and all Java type doc to check whether they might get broken. This needs > > to be listed in the removals doc. > > I think that is how we define API. IIRC the removal was started in 4.2 (I > was not involved in this discussion) so John or Paul might have more info > on this. We agree that the removal was not communicated/written well enough. > If we can't add code that simply supports > > the old-style of the extension point, then we have to revert the compat > > layer for 4.5. > > The removal and / or deprecation of the compatibility resulted in several > commits all over the places, I don't think it is realistic or desirable to > restore it in M7. I'm pretty sure we could revert the responsible commits, but it should also be possible to support the old-style extension point without doing that.
For reference, the info that this described usage of the extension point is deprecated, should no longer be used and depends on the comp. layer seems to have added 2006 with the following commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=6c0feb455e1e3b22c5bd7a0c979ead667c317d2d
> For reference, the info that this described usage of the extension point is > deprecated, should no longer be used and depends on the comp. layer seems to > have added 2006 with the following commit: > > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/? > id=6c0feb455e1e3b22c5bd7a0c979ead667c317d2d This by itself is insufficient as a means to properly notify the community of deprecation and eventual removal. It doesn't account for existing extensions. It doesn't account for the fact that extensions are often added by copy-paste from other plugins. It doesn't account for the fact that extension point documentation, especially for simple extension points, is often never read. Note that I am not asking for a reversal. My goal is ensure that similar changes are communicated better next time and to ensure that the bundles with breaking API changes have an incremented major version component.
(In reply to Konstantin Komissarchik from comment #18) > Note that I am not asking for a reversal. My goal is ensure that similar > changes are communicated better next time and to ensure that the bundles > with breaking API changes have an incremented major version component. I agree to that, as soon as we in the platform.ui realized that this info was missing we added it to the migration guide for 4.5 (beginning of this year) See https://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=bddd25a0ff2903c4edfdec84f7c21dc025401784 I was not aware that this stuff is communicated also via email
(In reply to Dani Megert from comment #16) > I'm pretty sure we could revert the responsible commits, but it should also > be possible to support the old-style extension point without doing that. The old-style way already heavily relied on reflection. Now, instead of calling removed methods we can get the bundle activator from BundleContextImpl via reflection in case the class attribute is not there. In addition we log a warning, telling that this should be fixed in the code. A test also needs to be added which verifies that the reflection still works in newer releases. Lars, or anyone else on this bug, can you provide a Gerrit change for review? Thanks.
I try to look this next week, can't promise anything, as I already have lots of other things on my hand. So is someone else can pick this up, that would be great. Can also clients indicate how important that temporary support is for them? The solution on the client side is relatively easy IMHO.
(In reply to Lars Vogel from comment #21) > Can also clients indicate how important that temporary support is for them? > The solution on the client side is relatively easy IMHO. No one doubts that it is easy to fix on the client side. But assume you have downloaded a few plug-ins some time ago and they are no longer maintained. Maybe you even only have the binaries. You would be pretty frustrated that you can no longer use it, and so would I be.
This is actually trivial to fix since the compatibility layer is still there in 4.5. I've reverted the change from bug 44584 and also log a warning when the 'class' attribute is not there. Fixed with http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=4d6cbc5234a2d5216fdaf1551bc5b69ee25507e7 Bug 445484 has been reopened to properly announce the change in 4.5 and remove it during 4.6.
(In reply to Dani Megert from comment #23) > I've reverted the change from bug 44584 Sorry, it's bug 445484.
*** Bug 457132 has been marked as a duplicate of this bug. ***
Thanks Dani for handling the fix for 4.5.
FWIW, I'm linking the two most popular platform error reports (in total ~1.000 users) to this bug. https://dev.eclipse.org/recommenders/committers/confess/#/problems/551194a2e4b0b71121dad676/details https://dev.eclipse.org/recommenders/committers/confess/#/problems/54c4f0a7bee810030da08462/details
New Gerrit change created: https://git.eclipse.org/r/52879
