Community
Participate
Working Groups
When I start up eclipse with a workspace that has no projects shared with cvs the cvs plugins are activated due to the decorator. This is the stack trace I got using Platform Core Tools. Activating bundle: org.eclipse.team.cvs.ui Bundle activation stack: org.eclipse.team.cvs.ui Class loading stack: Stack trace: java.lang.Throwable at org.eclipse.core.runtime.internal.stats.StatsManager.traceActivate(StatsManager.java:167) at org.eclipse.core.runtime.internal.stats.StatsManager.startActivation(StatsManager.java:141) at org.eclipse.core.runtime.internal.stats.StatsManager.watchBundle(StatsManager.java:111) at org.eclipse.osgi.baseadaptor.BaseAdaptor$2.watchBundle(BaseAdaptor.java:375) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:307) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:256) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.preFindLocalClass(EclipseLazyStarter.java:86) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:409) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:188) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:339) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:391) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:352) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.osgi.framework.internal.core.BundleLoader.loadClass(BundleLoader.java:276) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:227) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1245) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:147) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:759) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:242) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:49) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:238) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition$1.run(LightweightDecoratorDefinition.java:117) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.internalGetDecorator(LightweightDecoratorDefinition.java:113) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:241) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:71) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at org.eclipse.core.runtime.Platform.run(Platform.java:843) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:336) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:322) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:338) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:308) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
See bug 144475 for ideas on how to fix this issue.
From the trace, it appears that the CVS decorator is enabled. For usability, we enable the decorator the first time the CVS plugin is loaded. You must have done something at some point to cause the CVS plugin to load (e.g. opened a CVS wizard). You can manually turn off the decorator on the Label Decorations preference page. A better approach for CVS would be to hold off enabling the decorator automatically until we are certain tht the workspace contains a CVS project. However, this would be much more work to get right. Given that it is unlikley that a user would perform a CVS operation unless they intended to use CVS, we do not intend on implementing the deluxe solution for this.
Created attachment 47620 [details] the .options file I can confirm that without using any CVS views, menus etc the CVS plugins are activated by the CVS Decorator on a workspace with no open projects. 1. Open eclipse, install the platform core spy tools (v 1.4) from http://eclipse.org/eclipse/platform-core/updates and restart 2. close all your projects, go to the resource perspective and close any cvs related views 3. turn to the runtime spy perspective and close eclipse 4. place the attached .options file where the eclipse.exe is 5. start eclipse using -debug file:c:.options (change c: with your drive letter) you will see that the CVS plugins are NOT activated 6. turn to the resource perspective 7. turn back to the runtime spy perspective and press refresh on the 'activated plugins' view you will see that both cvs ui and cvs core are activated, from the stack trace recored by the spy tools you will see that the cvs decorator is responsible for the activation. WTP had the same issue, see bug 144475, AJDT has the same issue but they are working on solving it, see bug 152922.
Yes, what you describe is what I would expect to happen. Because you had CVS projects and/or CVS views open, the CVS decorator would become enabled. Once this happens, the user must disable the decorator manually if they wish to prevent the decorator from being loaded.
I believe the proper solution here is to associate an enablement rule with a lightweight decorator that can be tested before the decorator is loaded. In other words, a lightweight decorator shoudl have a user enablement setting (from the prefrence) and an enablement expression that bith must be on before the lightweight decorator class is consulted.
Decorators are using the enablement rules but the current set (the ui enablements) are not robust enough to handle this case. We should move to the core expressions enablement rules.
Oleg is now responsible for watching the [Decorators] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
