Community
Participate
Working Groups
When I start eclipse, with a blank workspace, even thought I have not opened any mylar views, haven't defined task repositories or queries the following plugins are activated: org.mylar.bugzilla.ui org.mylar.bugzilla.core org.mylar.trac.ui org.mylar.jira org.tigris.jira.core All these seem to be activated by the following code: 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.mylar.internal.tasks.ui.util.TasksUiExtensionReader.readRepositoryClient(TasksUiExtensionReader.java:223) at org.eclipse.mylar.internal.tasks.ui.util.TasksUiExtensionReader.initExtensions(TasksUiExtensionReader.java:109) at org.eclipse.mylar.tasks.ui.TasksUiPlugin$6.run(TasksUiPlugin.java:350) It should be best to defer the creation as late as possible or avoid it when there are no repository queries defined. Also there is no need to activate all the repository providers. Only those that are actually needed.
Thanks for posting. Mik will address the lazy loading of connectors as soon as he returns from vacation (~August 18th).
Our current modularity requires the Task List (i.e. org.eclipse.mylar.tasks.ui) to load all available repository Connectors on startup. This is because the repository Connectors define how to work with Task List elements that they understand (e.g. if a JIRA task exists in the tasklist.xml file it needs to be parsed by the JIRA Connector on startup). What we gain by the extension-point based loading of connectors is their pluggability--you can disable connectors and uninstall them as needed. Since this is not a simple UI dependency I don't see how we can support that pluggability without forcing the extension-point based loading, but let us know if you have any ideas. Also, is the loading causing a problem, or is the concern here that we're not adhering to the generally beneficial Eclipse lazy-loading rule?
No the current implementation is not causing any problems but i think that it is important to fix this because in the future there will be many repository providers. This is important when mylar part of a bigger distribution. Currently, even with a blank workspace mylar and the connectors are activated, (the same applies to all team repository providers) What I propose i a lazy initialization mechanism that initializes the spesific provider only when it needs it. For example the bugzilla provider should be initialized only when the user has added a bugzilla query or bugzilla task. The idea is to delay IConfigurationElement.createExecutableExtension as much as possible. I think that it will need some work and it can be done, I also think that it is something that must be done early because it will need api changes. I examining the code and noticed that most of the calls to TaskRepositoryManager.getRepositoryConnectors() is needed to obtain information about the repository connectors that could be obtained from the configuration element without calling createExecutableExtension. Therefore I propose to introduce a new class called RepositoryConnectorDescription that can be initialized using the configuration element (without calling createExecutableExtension) and change the TaskRepositoryManager to return those light objects. A new method should be added in TaskRepositoryManager to return actual AbstractRepositoryConnector when it is needed. In TaskRepositoryManager the only method I saw that actually needs the AbstractRepositoryConnector is getRepositoryForTaskUrl. Even this can be optimized to activate only those that are needed before it finds the right one. A similar approach could be used for other extensions like externalizers etc.
Need to postpone until after 1.0, at which point we will be restructuring our dependencies. This extra laziness will be a tricky change because the connectors' core plug-in controls the additional XML elements that are written out in the Task List, and hence without the connector present the corresponding parts of the tasklist.xml can not be read. That said, our goal will be to defer creating the executable extension for the connectors until they are needed, as described by comment#3. We may be able to do this by changing the tasklist.xml format to use an element name that the extension point reader can correspond to the connector via the extension registry. Downgrading to "normal" since with the current set of all available connectors the extra memory overhead is negligible.
We've made initialization considerably lazier in the 3.0 cycle, but repository connectors still need to be read on startup so that they can read the corresponding Task List XML entries. Postponing additional considerations on making the startup lazier.
Ideas that we have discussed: * Remove early startup for o.e.m.tasks.ui and spawn background synchronization job when task list view is first opened * Investigate if Team UI startup can be coupled to initialization of Synchronize view
Closing as part of backlog cleanup. Please reopen if you are working on this.
