Community
Participate
Working Groups
Version: 3.3.0 Build id: I20070323-1616 (3.3 M6) - installed all currently Europa installable features on top my fresh M6 install - instrumented core.runtime to track plugin activation - found that for base 3.3 M6, 36 plugins were activated, whereas 92 were activated for europa - wonder how I could activate / de-activate some feature base on the work I intend to do (ex: work on Database or develop some C/C++) Based on what is already done in Eclipse based toolkits such as WID/RAD, we could improve / optimize the number of features / plugins loaded at startup based on corresponding capability. Each feature could contribute the Capabilities preference page: - capability enabled: feature / plugins loaded at startup - capability disabled: feature / plugins not loaded at startup I went to the Capabilities preference page and found that only the BIRT feature was contributing to this page (compared to base Eclipse). See also bug 136397
Created attachment 65584 [details] screen shot current europa capabilities preference page
Capabilities is one thing but we should also check why those plug-ins get loaded at all.
(In reply to comment #1) investigation currently in progress: instrumented core.runtime to track early plugin activation along with stack trace. Comparing base Eclipse to "nearly full" europa results.
(In reply to comment #3) It was a reply to comment #2, not #1
You might want to use the Core Tools: http://www.eclipse.org/eclipse/platform-core/downloads/tools/org.eclipse.core.tools_1.4.0.zip
See also http://borisoneclipse.blogspot.com/2007/03/who-is-to-blame.html (really easy to use by everybody because it is a plug-in you drop into your install, it does not require command line settings)
Who do you want to take action? All projects contributing to the Europa release train?
Eric, can you assess and also post a heads/up reminder to the cross project mailing list?
Is there anything we (Platform UI) can/should do? If not, individual bugs against the projects in question should be filed.
Boris, I don't think you can do anything here. The only thing where Plat UI is a known cause for early loading is bug 136397 where we would need some advice form SWT. Eric to file bugs. Please cc me.
This bug is still assigned to Platform UI. Can it be moved somewhere else? I don't mind it being classified as Platform UI, I just would like to change the assignee because we try to keep our inbox empty.
(In reply to comment #6) Boris, we already use your plugin which turns to be very helpful.
(In reply to comment #11) Switched to Cross-Project component
(In reply to comment #8 and comment #10) next actions: - send a heads-up to to the cross project mailing list - open one individual bug per europa feature (cc Daniel)
Do I understand this right: * Plugins/Features that contribute to the UI through plugin.xml are OK, as long as the plugin is not automatically activated when starting Eclipse in the default Perspective. * In case plugins are activated, plugin owners should check whether activation is really necessary or could be deferred e.g. by declarative contribution to the UI rather than programmatic contribution. * In case there are UI or other contributions that do require plugin activation or cannot be converted to being declarative in time for Europa, plugins should contribute to the Capabilities extension such that this activation can be suppressed. I think it would help if somebody could point us to sample code how to contribute to the Capabilities extension properly (ideally with some sample code and XML, perhaps from BIRT?
These were my comments on the cross project mailing list For EMF we have capabilities defined in an example plugin. We ran into problems with providing these as an actual part of our standard feature since IBM products wanted to define their own notion of what functions fits in what capability categories. So if the idea is that Europa will now deliver on the order of 20 or more categories out of the box, I'm not sure that's a great idea. Is it possible to use capabilities to filter out capabilities themselves so they can be redefined differently by a client who has their own notion of how best to group the function contributed by various Eclipse projects into categories of capability? I fear that an uncoordinated effort will just result in a hodgepodge of categories and I don't think EMF will be in a position to contribute to that (and reading the bugzilla I don't think EMF loads plugins before their time is right). So a word of caution, be careful what you ask for, you may get it. I also wonder if people think it's realistic to ask others to ship their features with their capabilities disabled. I know that when people install EMF directly they are really expecting it to be enabled and I'm sure every project is in the same position in that regard. Is there a declarative mechanism whereby products could change the default enableblement state of various capabilities?
When I got this right, the idea was not necessarily to have it disabled by default, but to give the user the ability to disable it. I agree that the responsibility for defining the granularity of Capabilities seems to be with the products based on Eclipse (and not the core framework, Eclipse itself). Having a second level of enablers ("Capabilities of Capabilities", or "Capability Enablers", or "defined but currently hidden Capabilities") seems like an interesting idea.
(In reply to comment #15) > Do I understand this right: > > * Plugins/Features that contribute to the UI through plugin.xml are OK, as long > as the plugin is not automatically activated when starting Eclipse in the > default Perspective. > --> correct, in my opinion > * In case plugins are activated, plugin owners should check whether activation > is really necessary or could be deferred e.g. by declarative contribution to > the UI rather than programmatic contribution. > --> agreed: that's one main point - check whether plugin activation is expected > * In case there are UI or other contributions that do require plugin activation > or cannot be converted to being declarative in time for Europa, plugins > should contribute to the Capabilities extension such that this activation > can be suppressed. > --> the main idea of this thread is (according to me): even if plugin is installed or contributes to such pull-down menu, or have an icon - whatever plugin activation may be - contributing to the General / Capabilities preference would enable end-user to be able to activate/deactivate desired plugin(s) based on intended usage of the Toolkit. > I think it would help if somebody could point us to sample code how to > contribute to the Capabilities extension properly (ideally with some sample > code and XML, perhaps from BIRT? >
(In reply to comment #16) As suggested by Ed, we may come up with a capabilities hiearchy that matches the categories displayed in the update wizard, when installing europa. Grouping might be similar as what can already be found in 3.3 M6 (see screen shots). Doing this way would prevent us from having too many items in the General Capabilities pref page confusing the end-user.
Created attachment 65761 [details] Install Europa: component categories
Created attachment 65762 [details] 3.3.M6 Advanced Preference Page
Note that capabilities are mainly used to filter declarative contributions to the UI. Disabling a capability has no impact on the runtime level, and won't necessarily prevent a plugin from being activated. Eric, do you have evidence that defining capabilities would reduce the number of plugins that get activated? We should avoid asking all Europa projects to do anything until we know if it will have the desired effect. Ed's point is also very important. If Europa had an associated product plugin, that would be a reasonable place to define capabilities. It generally isn't appropriate to define capabilities at a lower level, because larger Eclipse-based products may want a different level of granularity in their capabilities.
(In reply to comment #22) John: no evidence here, as I'm talking about an enhancement / new feature to implement. (see my last comment about how we could categorize projects / features) I already opened 4 child bugs, but you're right: better have a common way to handle this in order to provide component owners with some guidelines. I stand by with child bugs for now until a common agreement is found.
Child bugs: AJDT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185335 BIRT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185336 Buckminster: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185341 CDT: https://bugs.eclipse.org/bugs/show_bug.cgi?id=185342
Moving to UI Group.
