Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 Build Identifier: Hi, this is a follow up on the following post: http://neilbartlett.name/blog/2009/11/30/osgi-its-time-to-ban-bundle-activators/ According to this discussion Activator should be avoided. I suggest therefore that PDE should not create a Activator as default in a new plugin project. Best regards, Lars Reproducible: Always Steps to Reproduce: Create a new plugin project-> "Generated an activator, a Java class that controls the plug-in's life cycle" is flagged as default.
*** Bug 297406 has been marked as a duplicate of this bug. ***
I don't want to let this bug be completely forgotten, but it is low priority so I don't expect any of the committers will be looking at this.
@Curis: Would you apply a patch if I provide one to change the default flag?
Most of the Eclipse plug-ins are still using them and the blog referenced in this bug has been taken down. cc'ing Tom. Is the use of bundle activators actively discouraged?
@Curtis: Theses day I wouldn't say actively discourage but I think the default should switch. AFAIK the Activator is rarely used. I might be wrong here.
+1 I develop lots of bundles, and it's rare that I want an activator.
This is in reference to Lars Vogel's tweet: https://twitter.com/vogella/status/226071553262096385 We do use Activator, since it seems to be mentioned in every eclipse plugin tutorial i have come across. There is nothing on this bug which indicates why we should abandon it and what are the alternatives. The blog post linked in the first comment gives a 404.
@Prashant it is not bad creating it, it is just an unused class in most cases for me. And I almost never use it.
(In reply to comment #8) > @Prashant it is not bad creating it, it is just an unused class in most cases > for me. And I almost never use it. @Lars it seems to have explicit start(), stop() methods. We use the 'start()' method to check for licenses. Also we override initializeImageRegistry() to initialize our image registry. There needs to be some code showing how to do this alternatively without creating an Activator class.
(In reply to comment #8) > @Prashant it is not bad creating it, it is just an unused class in most cases > for me. And I almost never use it. Also we use it all over our code to get access to things like preference store, image registry, and some custom fields that are initialized, etc. It acts as a global variable container for the rest of the plugin.
@Prashant: It is absolutely ok to use an Activator if you have the need to. Nobody will remove this option nor deprecate the usage. I'm just wondering if the majority of developers have the need or if your case is the exception.
(In reply to comment #11) > I'm just wondering if the majority of developers have the need or if your case > is the exception. IMOO, the question is also : "should we encourage the use of the Activator class? In order to encourage a (as far as can be) more standard code, and some good practices." An eclipse plugin must be as optimized and light as can be. Keeping this option on by default may be (indirectly) encouraging the use of Activators and therefore the use of 'start()' and 'initializeImageRegistry()' methods.
We do use Activators and I know this "central storage pattern". Nevertheless I consider singletons as a bad design idea in most cases. Change the default to not generate an Activator seems fine to me. In eclipse 4 @inject should be used rather than accessing a singleton Activator imo.
In Eclipse 3.x, I often used activators, at least for logging and for the management of image descriptors. I have not yet developped plugins for Eclipse 4 (I am still using the compatibility layer). If it was only for Eclipse 3, I would say we should keep the option in the wizard, but let it unselected by default.
In response to tweet of Lars, I never use the Activator. In rare cases i need to run early code i use the E4 lifecycle injection. Our team, as policy, states that Activators are not used. We never needed to deviate from that. We only use E4. (all E3 projects are migrated) I would vote to stop generating the Activator by default. (and maybe allow lifecycle injection to occur using a fragment?)
The main reason in the past for using a BundleActivator was to inform the bundle when it has a valid bundle activator and could interact with the the OSGi service registry, obtain services, initialize the services it provides and register them etc. In other words when the bundle is being activated. There are now several injection containers (or extenders) that provide better models on top of the OSGi service registry that make the use of BundleActivators unnecessary. For example, declarative services, blueprint, ipojo, e4 etc. An issue I foresee with not making the creation of the BundleActivator the default is that PDE may soon be asked to pick a default injection container or extender to set the project up with. Generally there are three types of bundles. 1) Pure library bundles that contain code that has no lifecycle interaction with the OSGi framework. These bundles obviously need no bundle activator or injection container to interact with the OSGi service registry. 2) Classic OSGi bundles that interact directly with the service registry (use the BundleContext, ServiceTracker, and listeners (Bundle, Service, Framework). Also, bundles that need to manage the lifecycle layer of the framework may fall into this type: install, start, stop, uninstall of bundles (e.g. simple configurator) 3) Bundles that use some kind of extender to interact with the service registry. Perhaps PDE should give the developer a choice in setting up one of these three types of bundles? Short of doing that I don't see much advantage to changing the default.
When you also have "this plugin contributes to the UI" set, it generates an Activator based on AbstractUIPlugin (that gives access by default to image registries, image loading, bundle preferences, etc). If you want to make "Generate an activator..." default to off would you turn "contribute to UI" off? How do we allow them to toggle separately, but *if* "contribute to UI" is on then they most likely want access to all of the helpers provided by AbstractUIPlugin, and so "Generate an activator..." should be checked. PW
I think the discussion here showed that their is no common agreement to change the default. I'm closing this bug therefore as "Won't fix".
What about adding a preference that allowed you to specify the default?
@Brian: I think it would be nice if PDE would remember the last section by the user. Could you please open a new bug report for this?
Alex Blewitt is currently working relatively hard to remove Activators in platform to speed up the startup of Eclipse. I think we should reconsider the current default in PDE>
I agree; it makes sense for it not to be created by default. Maybe an option on the wizard, like 'contributes to UI?', to allow it to be created, but have it deselected?
(In reply to Alex Blewitt from comment #22) > I agree; it makes sense for it not to be created by default. Maybe an option > on the wizard, like 'contributes to UI?', to allow it to be created, but > have it deselected? We have this option already but currently selected by default.
(In reply to Lars Vogel from comment #23) > (In reply to Alex Blewitt from comment #22) > > I agree; it makes sense for it not to be created by default. Maybe an option > > on the wizard, like 'contributes to UI?', to allow it to be created, but > > have it deselected? > > We have this option already but currently selected by default. I just retested, at the option "Generate an activator.." is not selected in my wizard. Not sure if this selection is persisted these days or if we changed the default in another bug.
New Gerrit change created: https://git.eclipse.org/r/56577
By the way, this is still an issue - a freshly downloaded copy of Eclipse against an empty workspace still has the 'Create an Activator' selected by default. Even if it remembers you turning it off, it still encourages bad behaviour by defaulting to doing the wrong thing.
Created attachment 260300 [details] Screenshot showing default
(In reply to Alex Blewitt from comment #27) > Created attachment 260300 [details] > Screenshot showing default I don't think the default has changed yet. Maybe you want to restore and rework your Gerrit review which you started a while ago in comment 25?
Restored the change and rebased. Not restested it yet.
Retested commit. Still works as expected; the activator checkbox is no longer selected by default. Persistence for selected checkbox still works as expected between launches. This is ready to merge.
(In reply to Alex Blewitt from comment #30) > Retested commit. Still works as expected; the activator checkbox is no > longer selected by default. Persistence for selected checkbox still works as > expected between launches. > > This is ready to merge. Thanks, I test and merge this after M6 is released. Good to have you back in the code contributing camp, IMHO your contributions are highly valuable.
Gerrit change https://git.eclipse.org/r/56577 was merged to [master]. Commit: http://git.eclipse.org/c/pde/eclipse.pde.ui.git/commit/?id=c10a8080908b4d4cb6acdb76bdcad76bce05e0b3
Thanks Alex.
Verified in 4.6.0.N20160420-2000h
IMHO, this should be mentioned in N&N.
