Community
Participate
Working Groups
Build Identifier: M20110909-1335 The lazy loading mechanism of Eclipse Platform for plugins can cause the following problem: if you try to import in the workspace a project which had already been checked out from a Subversion repository into an external folder (with an external client), if the Subversive plugin has not yet started, the imported project won't be connected to SVN, although the Subversive option to automatically share project is enabled. The discussion is at bug #336689, which is marked as "fixed" but the fix is some kind of workaround that may work in some cases but not in others. If an extension point prior to project import existed, the Subversive plugin could use it to "intercept" that event and load itself in time for the automatic project sharing to work. Reproducible: Always Steps to Reproduce: Please see bug #336689 for the steps to repro. As a summary: checkout a project from SVN with an external Subversion client into an external folder, start Eclipse (with Subversive plugin but without Subversive-Mylyn integration) on a fresh new workspace, try to import the checked out project into the workspace => your project won't be connected to SVN.
I think it is not related to IDE but more like to Resources component, because the issue is related to the headless environments as well. Actually I've already tried to find a solution for the problem but without success. Currently I can listen to the project import events only by connecting my listener through Java code. But since plug-in is not loaded at startup, whatever I do have no effect at all, because there is no Java code to be executed due to lazy load policy. So, having some extension point that will allow to intercept the events will be really helpful.
I'm not sure how it is related to Resources. I tried similar steps for CVS client and it works fine, so SVN could do the same. If you are looking for a hook for importing/creating projects, you could use a resource change listeners, see IResourceChangeListener. Moving back to IDE.
(In reply to comment #2) > I'm not sure how it is related to Resources. I tried similar steps for CVS > client and it works fine, so SVN could do the same. If you are looking for a > hook for importing/creating projects, you could use a resource change > listeners, see IResourceChangeListener. > > Moving back to IDE. Hello Szymon, That is obviously the case with listening through IResourceChangeListener. But then could you please point me, how I can install a listener through the code, when plug-in itself is not loaded yet and will never be loaded if no one tried to access it first? Thank you in advance.
The guidelines for IDE plugins are 1) wait for a user operation to load your plugin 2) on load, check for any conditions that could have happened while in the STARTING state. Is it not possible for you to scan the list of projects after you've started and run the "oh, you're an unshared SVN project" code? Or is your code a contribution (like an extra page) in the Import wizard? Advanced plugin loading is to be avoided at all costs, as once your plugin has been activated the framework will load and instantiate all contributions it can within a very short amount of time (cost in performance and memory consumption). In RCP apps it is not an issue as RCP apps are free to start up whatever they want in their WorkbenchAdvisor#postStartup() method. PW
(In reply to comment #4) > Is it not possible for you to scan the list of projects after you've started > and run the "oh, you're an unshared SVN project" code? Or is your code a > contribution (like an extra page) in the Import wizard? I think the problem is that, after the import has finished, the user sees the projects as unshared. What the user should do to share them, apart from issuing a manual Team | Share project operation (which is exactly what we want to avoid)? Even though Subversive did such a scan, the user would be forced to do some action related to Subversive in order to "activate it", while the imported project should have all the SVN-related facilities already working after the import has finished, without the user having to do anything (unless the option to automatically share projects is unchecked). Please note that mine is just a user point-of-view Alexander knows the technical details.
(In reply to comment #4) I guess, you're refering to something like this? ISavedState ss = ResourcesPlugin.getWorkspace().addSaveParticipant(SVNTeamPlugin.instance(), this); if (ss != null) { ss.processResourceChangeEvents(this); } But after importing a project there were not a single change available (I don't think debug break point could influence it, right?). Another point is what will hapen if we're going with the flow (even if the import project event really was saved which is not the case): 1) We're starting IDE 2) Workspace is clean, so there are no interaction with the source control provider and it is not loaded 3) We're importing a bunch of projects with the SVN meta-info 4) We're expecting something...forever! There will be no automatic share of those projects until we do something that will cause SVN Team Provider to be loaded! And the last point is that WorkbenchAdvisor is something related to UI. And what will we do in the headless environment?
(In reply to comment #4) And there is more to be wary of, the real issue is not that the projects will not be shared, but that none of all the .svn folders with their contents will be marked as team private. Then those folders will interfere with the build process, after sharing the project they will be regarded as damaged parts of Subversion working copy etc.
(In reply to comment #6) > 4) We're expecting something...forever! There will be no automatic share of > those projects until we do something that will cause SVN Team Provider to be > loaded! yes. If the user does Team>Share, or switches to the SVN perspective or opens an SVN view, then your plugin will be activated and you can process existing projects to see if they are unshared but contain SVN metadata. This only applies to the IDE, and it is the expected behaviour for all plugins contributions. CVS behaves the same way, it doesn't get activated until a user action (and then occasionally responds with "Operation is not currently enabled"). The Eclipse IDE lazy loading policy trades accuracy for performance. > > And the last point is that WorkbenchAdvisor is something related to UI. And > what will we do in the headless environment? WorkbenchAdvisor is what RCP apps control in a UI environment (allowing an RCP app to circumvent the lazy loading policy). We don't have access to that in the IDE. In a headless environment you're in an equinox application. Then it totally depends on how your app starts up plugins. Did it specify start levels in osgi.bundles? If not, and your headless app also uses the standard equinox/plugin model (everything is lazy) and you want to force a bundle activation, you can do that via code in your IApplication start method. org.eclipse.core.runtime.Platform.getBundle(String) and then bundle.start(Bundle.START_TRANSIENT). PW
Extra information: A way to circumvent this that is least unpalatable is to write a small plugin that 1) has no UI contributions and 2) has almost no extension point contributions and 3) can do the simple checks you need on startup and only start other plugins if deemed necessary. Then you use org.eclipse.ui.startup to cause org.eclipse.ui.IStartup (not the activator) to be run soon after the workbench is realized. PW
(In reply to comment #7) > And there is more to be wary of, the real issue is not that the projects will > not be shared, but that none of all the .svn folders with their contents will > be marked as team private. Then those folders will interfere with the build > process, after sharing the project they will be regarded as damaged parts of > Subversion working copy etc. Yes, this is a major problem that was observed in other circumstances as bug #361831, but that still exists whenever bug #336689 is hit (as a consequence of the problem we're talking about).
(In reply to comment #8) > (In reply to comment #6) > > 4) We're expecting something...forever! There will be no automatic share of > > those projects until we do something that will cause SVN Team Provider to be > > loaded! > > yes. If the user does Team>Share, or switches to the SVN perspective or opens > an SVN view, then your plugin will be activated and you can process existing > projects to see if they are unshared but contain SVN metadata. > > This only applies to the IDE, and it is the expected behaviour for all plugins > contributions. CVS behaves the same way, it doesn't get activated until a user > action (and then occasionally responds with "Operation is not currently > enabled"). The Eclipse IDE lazy loading policy trades accuracy for > performance. And this is exactly what users see as an issue. There exists this saying that "premature optimization is the root of all evil". It's a joke, obviously, but there are some truth in it. As I said this behaviour will cause a lot of issues with a negative user expirience: 1) Many useless nodes in the Navigatore, Package Explorer etc. 2) Interference with the build process 3) Issues with the source control metainformation integrity 4) Failed user expectations We're not talking about something like forceful loading of source control plug-in. It will be pretty stupid, since the lazy loading policy is not that bad itself. But! When the project is imported - it is obviously the point where the team providers core (and core only) plug-ins could be loaded to check if some actions are required. And more over, there could be some expressions/data in the extension point specification, that will allow to load only the team provider plug-in related to the project. For example it could be something like a filter, saying to load SVN Team Provider if there is a .svn folder inside the project folder or load CVS Team Provider if there is a CVS folder. I know of the org.eclipse.ui.IStartup extension point existance, but I don't think it is suitable for the task. 1) As I've mentioned before, the solution should work in any headless environment too 2) Also there should be no way to disable it through preferences (it is not the same as disabling autoshare, we still should mark team-private members!)
(In reply to comment #11) > And this is exactly what users see as an issue. There exists this saying that > "premature optimization is the root of all evil". This optimization was added long ago after a consistently reported problem by users. There was a lot of debate about the pros and cons before it was implemented, but it was the solution that was picked. The cost of having all plugins activated on startup is huge, especially when you start adding a number of different projects (CVS, SVN, EGit, Xtext, EMF, WTP, XML Editors and tools). Plugins must avoid starting up without a user action at all costs. > 1) Many useless nodes in the Navigatore, Package Explorer etc. > 2) Interference with the build process > 3) Issues with the source control metainformation integrity > 4) Failed user expectations In the Eclipse IDE, this lazy startup has been that way for a long, long time. When unknown that it's the standard policy for the entire Release Train stack yes, it can lead to some user confusion. But long startup also cause failed user expectations, and a huge consumption of memory does as well. And AFAICT this is a corner case. The user starts up, externally uses SVN to get their projects, and imports them into eclipse without ever touch SVN plugin functionality. Presumably they don't then import external projects into empty workspaces all the time, and starting up with even one SVN project (which has decorators and would cause activation) is enough to prevent the problem ever again. Slow startups and huge memory consumption continue to be an issue in the release stack, and for us (in the framework) we want to avoid that at all costs. > I know of the org.eclipse.ui.IStartup extension point existance, but I don't > think it is suitable for the task. > 1) As I've mentioned before, the solution should work in any headless > environment too In the headless environment you have a different way to start up plugins. You wouldn't want to pull the >4Meg workbench just to start up a plugin. That would make your headless tool startup time comparable to the UI :-) Starting the small startup plugin from an headless app would work the same way, arguably. > 2) Also there should be no way to disable it through preferences (it is not the > same as disabling autoshare, we still should mark team-private members!) The user can disable them if they really want to ... but 1) don't often because they don't know what they do and 2) if they did, then they would have a problem and would quickly re-enable them. PW
(In reply to comment #12) > And AFAICT this is a corner case. The user starts up, externally uses SVN to > get their projects, and imports them into eclipse without ever touch SVN plugin > functionality. Presumably they don't then import external projects into empty > workspaces all the time, and starting up with even one SVN project (which has > decorators and would cause activation) is enough to prevent the problem ever > again. I understand your point, but it sounds just like "if because of the missing handrails on the ladder one of the ten people will break their neck - it is not a problem at all because nine of them will still be safe". :-) > Slow startups and huge memory consumption continue to be an issue in the > release stack, and for us (in the framework) we want to avoid that at all > costs. I understand, that is why I've proposed an idea that will allow to cover the case without excessive memory/CPU consumption: an extension point. And we even can merge it with your idea regarding "small plugin": small plug-in that implements extension point reacting to the resource addition event, that will cause loading the main plug-in only if it is required. P.S. I understand that when we're in the IDE, we can use IStartup but I still find it inappropriate because it won't work outside graphical environment and could be disabled. And this is exactly the reason why I tried to move the issue report to the Resources component.
(In reply to comment #12) > And AFAICT this is a corner case. The user starts up, externally uses SVN to > get their projects, and imports them into eclipse without ever touch SVN plugin > functionality. Presumably they don't then import external projects into empty > workspaces all the time, and starting up with even one SVN project (which has > decorators and would cause activation) is enough to prevent the problem ever > again. There are use cases for which this is not a corner case. When you work with Gradle multiprojects, since Eclipse does not support nested projects, the typical workflow is the following: - checkout the whole multiproject on an external folder (I mean "external" relative to the workspace) with an external SVN client - import the multiproject in the workspace using Spring Tools Suite Gradle Integration Import Wizard (which may or may not do some Eclipse projects setup; in our case, it's used just like the standard Import Existing Projects Into Workspace, except that this one doesn't let you import nested subprojects of a Gradle multiproject) - start to work on your projects, which should appear as already shared and without missing SVN metadata due to this problem > Slow startups and huge memory consumption continue to be an issue in the > release stack, and for us (in the framework) we want to avoid that at all > costs. I think the problem here is not that we want to consume memory or to slow down the platform startup, but that there should be a way for the SVN plugin to be loaded before any action is performed that needs the SVN plugin to be already loaded and active. The import of projects into the workspace is one of them and this is the reason of this enhancement request. If you think there could be another way to do what is needed, without adding an extension point, I think Alexander would be glad to try it, but I don't think the best answer is to say that there is no problem here or that this is a "corner case" to ignore. Please forgive me if I misunderstood.
(In reply to comment #14) > - start to work on your projects, which should appear as already shared and > without missing SVN metadata due to this problem Sorry, this should be read: "without *corrupted* SVN metadata".
(In reply to comment #13) > I understand, that is why I've proposed an idea that will allow to cover the > case without excessive memory/CPU consumption: There's a cost associated with extension points in maintenance for the implementation and API (and once published API can only evolve in one direction). And solving this problem for the many extension points that all have that one or two corner cases could consume an entire release. We have a general solution for plugins that really have a situation where they can't wait for user action. A small plugin to evaluate when things need to be started up that uses an early startup extension for use in the IDE. > > P.S. > I understand that when we're in the IDE, we can use IStartup but I still find > it inappropriate because it won't work outside graphical environment and could > be disabled. And this is exactly the reason why I tried to move the issue > report to the Resources component. The small plugin that can determine the condition to activate is the solution. IStartup when in the UI to start the plugin at the appropriate time, and Platform.getBundle(*) to start the plugin with fine grained control in headless equinox or OSGi applications. That the startup extensions can be disabled is the trade-off for people that hate having things start up when they fire up eclipse. But even they turn it back one when told it must work that way. PW
(In reply to comment #14) > I think the problem here is not that we want to consume memory or to slow down > the platform startup, but that there should be a way for the SVN plugin to be > loaded before any action is performed that needs the SVN plugin to be already > loaded and active. The small plugin that can make a determination and the startup extension point is the general solution for situations where a project *must* circumvent the lazy loading strategy. PW
Hi Alexander, do you have decided something about this? Should we open a new bug or move this to Subversive?
(In reply to comment #18) Hello Mauro! I think I won't hit the wall with my head anymore. If it is all right to have such an unobvious issue then there is nothing I can do. I'll reopen the original issue report, then use the UI IStartup extension point to handle it in the Eclipse IDE (hoping there won't be anyone who will disable it in their environments) and expect that the people responsible for their headless environments will handle the case properly as well. P.S. So, if there are no plans to provide an extension point for the issue, please feel free to close this report.
(In reply to comment #19) > P.S. > So, if there are no plans to provide an extension point for the issue, please > feel free to close this report. Thank you Alexander. I'll leave the decision to reject this request or not to the Platform dev team.
.
In order to fix bug 460018 right way we need bug 364569 to be reopened and fixed. Anything else are workarounds. It's platform duty to make sure that appropriate team providers are lazy loaded for project import, not other way around. I don't see why should egit/svn/whoever *each one* provide extra plugins which must implement IStartup and always activate egit/svn/whoever as bundles (proposed in comment 16) even if no import functionality is requested. Since team providers are only used in IDE's, each of them could for sure directly contribute IStartup's, but this drives all those recently started platform startup enhancement initiatives ad absurdum. We should provide an extension point in platform which would only be used *if needed* (truly lazy loading) during project import and not force each and every team plugin provider to add overhead to the platform by contributing extra bundles to IStartup and finally loading all team plugins even if the user don't need all of them at all.
