Community
Participate
Working Groups
Created attachment 210482 [details] The example project to be employed to verify the bug. Overview: When calling new DotGraph() within a plugin in a minimal installation, the MWE standalone setup (see link below) is triggered on the Eclipse installation directory. This causes MWE to index the whole content of the Eclipse installation, which takes a long time. http://wiki.eclipse.org/Xtext/FAQ#How_do_I_load_my_model_in_a_standalone_Java_application.C2.A0.3F Steps to Reproduce: 1) Obtain an Eclipse 3.7 installation that includes PDE (e.g. Eclipse Classic) 2) Extract the attached demo project into your workspace. 3) Set the zest_dot.target as the current target. 4) Close any other projects in the workspace except the example (org.be.textbe.gv.view). 5) Create a run configuration with the following settings: - An Eclipse Application - Main: * Clear: workspace * Run a Product: org.eclipse.platform.ide * jvm 5 or 6 -Plugins * all workspace and enabled target plugins - Configuration: Clear the configuration area before launching 6) validate the configuration 7) apply the configuration 8) run the configuration 9) The new eclipse instance starts up. 10) Close the welcome page 11) Select window->show view->other 12) From the window select Behavioural Engineering -> Behaviour Tree View and confirm with ok. 13) Observe that the user interface of the new Eclipse instance freezes. 14) Observe the console of your host Eclipse instance. It will print log messages similar to those shown below: Feb 03, 2012 9:32:09 AM org.eclipse.emf.mwe.utils.StandaloneSetup setPlatformUri INFO: Registering platform uri 'C:\Program Files' Feb 03, 2012 9:32:24 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\artifacts-898540412.jar. Feb 03, 2012 9:32:24 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\artifacts1770871909.jar. Feb 03, 2012 9:32:25 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\compositeArtifacts-2043338285.jar. Feb 03, 2012 9:32:25 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\compositeArtifacts1336844219.jar. Feb 03, 2012 9:32:25 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\compositeArtifacts2069679319.jar. Feb 03, 2012 9:32:25 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\eclipse\p2\org.eclipse.equinox.p2.repository\cache\compositeArtifacts682498812.jar. Feb 03, 2012 9:38:13 AM org.eclipse.emf.mwe.utils.StandaloneSetup registerBundle WARNING: Could not open Jar file C:\Program Files\eclipse\..\Mozilla Firefox\omni.jar. log4j:WARN No appenders could be found for logger (org.eclipse.xtext.parser.antlr.AbstractInternalAntlrParser). log4j:WARN Please initialize the log4j system properly. Actual Results: Depending on the size of your host instance installation in files and bytes, the view initialisation can take several minutes. Expected Results: The view instantiation is instanteneous. Additional Information: * Conjecture on the nature of the bug: The MWE activator gets called and finds that in implicit dependency or service is not present. It hence switches to stand-alone mode and begins the scan.
Thanks for the report. I tried to reproduce the problem with your project and instructions but there is no major delay here when I open the view. In the log, I only get one output like this: Feb 5, 2012 8:55:00 PM org.eclipse.emf.mwe.utils.StandaloneSetup setPlatformUri INFO: Registering platform uri '/Users/fsteeg/eclipse/Eclipse.app/Contents' From your log output it seems this step is somehow broken, with files not being found. Could it be related to restricted access rights or whitespace in the path to your installation (C:\Program Files\eclipse)?
I have verified that there were actually corrupt files in the cache. I have deleted the files by emptying the cache. They also do not appear on an otherwise unchanged installation. The log now reports: "Feb 06, 2012 10:19:49 AM org.eclipse.emf.mwe.utils.StandaloneSetup setPlatformUri INFO: Registering platform uri 'C:\Program Files'" This explains the slow startup! It is not the eclipse directory that is being indexed, but the eclipse install PARENT!! On windows this means mayhem if you install, as I do C:\Program Files\eclipse rather than C:\Program Files\indigo\eclipse With indigo being empty except for the install. This will help me patch around this. I have no idea how MWE decides on this path. The Mac version apparently stays neatly within bounds (i.e. inside the install path archive) Irrespective of >> why MWE starts in standalone mode and >> how MWE resolves its standalone index path on various platforms. I still believe that >> implicitly invoking MWE through a dependency from dot4zest is a bug, since MWE is not actually required to use dot4zest. Dot4zest and its languages are all binary compiled. There is no need to run a build to create new languages. If dot4zest depends on any runtime libs in MWE these libs should be extracted and included explicitly. I have tried to unfold the dependency tree of dot4zest. My machine froze on the attempt, and eventually died with an out of memory error. To me it seems unusual (and unlikely) for a plugin to have such a large dependency scope.
Below is the call stack the causes the indexing behaviour: StandaloneSetup.setPlatformUri(String) line: 126 DotAst.loadResource(File) line: 155 DotAst.<init>(File) line: 94 DotImport.load() line: 92 DotImport.loadFrom(String) line: 74 DotImport.init(String) line: 66 DotImport.<init>(String) line: 58 DotGraph.<init>(String, Composite, int) line: 37 The bug is in DotAst.loadResource(File) line: 155 private static Resource loadResource(final File file) { >> new StandaloneSetup().setPlatformUri(".."); //$NON-NLS-1$ DotStandaloneSetup.doSetup(); Since eclipse runs in C:\Program Files\eclipse The indexer runs in C:\Program Files\ The function org.eclipse.emf.mwe.utils.StandaloneSetup.scanFolder(File, Set<String>) than does a recursive scan of that directory. Tick...Tick...Tick Could you fix this?
The issue seems to be that the code makes implicit assumptions about the property user.dir. A pathname, whether abstract or in string form, may be either absolute or >>relative<<. An absolute pathname is complete in that no other information is required in order to locate the file that it denotes. >>A relative pathname, in contrast, must be interpreted in terms of information taken from some other pathname.<< By >>default<< the classes in the java.io package always resolve relative pathnames against the current user directory. This directory is named by the system property >>user.dir<<, and is >>typically the directory in which the Java virtual machine was invoked<<. from http://docs.oracle.com/javase/1.5.0/docs/api/java/io/File.html The parameter ".." is evaluated relative to ${user.dir}, which may be anything, but on windows inside eclipse resolves to the eclipse install directory. private static Resource loadResource(final File file) { new StandaloneSetup().setPlatformUri(".."); //$NON-NLS-1$ DotStandaloneSetup.doSetup(); Iam not sure what the developers intention is, but propose that this might be * patched with to index nothing (an empty directory) for a fast startup. * fixed with a config parameter and dialogue.
Thanks a lot for investigating. It actually seems that both the calls to setPlatformUri() and doSetup() are not (or no longer) necessary. Having removed them, the issue should be fixed now - it would be great if you could confirm.
There is a different invocation path that still triggers the same behaviour: Graphical Editing Framework Zest Visualization Toolkit SDK 2.0.0.201202102322 /org.eclipse.zest.dot.core/org.eclipse.zest.dot.core_2.0.0.201201190220.jar Below is the trace from createPartControl() [all the way atthe bottom]in the example via the constructor for DotGraph() leading to loadResource() [at the top]. loadResource(File) : Resource - org.eclipse.zest.internal.dot.DotAst DotAst(File) - org.eclipse.zest.internal.dot.DotAst load() : void - org.eclipse.zest.internal.dot.DotImport DotImport(File) - org.eclipse.zest.internal.dot.DotImport DotImport(IFile) - org.eclipse.zest.internal.dot.DotImport loadFrom(String) : void - org.eclipse.zest.internal.dot.DotImport init(String) : void - org.eclipse.zest.internal.dot.DotImport (2 matches) DotImport(String) - org.eclipse.zest.internal.dot.DotImport add(String) : DotGraph - org.eclipse.zest.dot.DotGraph DotGraph(String, Composite, int) - org.eclipse.zest.dot.DotGraph createPartControl(Composite) : void - org.be.textbe.gv.bt_view.views.BT_View the method loadResource() (i.e. org.eclipse.zest.internal.dot.DotAst.loadResource(File) located in /org.eclipse.zest.dot.core/org.eclipse.zest.dot.core_2.0.0.201201190220.jar) still begins as follows: private static Resource loadResource(final File file) { new StandaloneSetup().setPlatformUri(".."); //$NON-NLS-1$ ... The behaviour is consequently still the same. Maybe the change has not been promoted and shipped? In order to see the issue, set the >>user.dir<< property to force the issue. A full (i.e. ".." of "/var") or non-existing (i.e. ".." of "/") superdirectory may produce interesting outcomes.
Just confirming that Git ref 0c1db8a5e2b4f40f2d919a3e910ad6b911d3a0f4 still has private static Resource loadResource(final File file) { >>> new StandaloneSetup().setPlatformUri(".."); //$NON-NLS-1$ DotStandaloneSetup.doSetup(); Which causes the behaviour. I see the removal of the ref to the setup and this is good, but it does not cause the issue.
Sorry, was not on the nightly build. Working now in org.eclipse.zest.dot.core_2.0.0.201202102322.jar
