Bug 370511

Comment 1 Fabian Steeg 2012-02-05 15:16:57 EST

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)?

Comment 2 Jörn Guy Süß 2012-02-05 19:46:47 EST

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.

Comment 3 Jörn Guy Süß 2012-02-05 20:04:41 EST

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?

Comment 4 Jörn Guy Süß 2012-02-05 21:12:32 EST

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.

Comment 5 Fabian Steeg 2012-02-10 18:40:54 EST

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.

Comment 6 Jörn Guy Süß 2012-02-12 19:31:54 EST

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.

Comment 7 Jörn Guy Süß 2012-02-12 19:42:59 EST

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.

Comment 8 Jörn Guy Süß 2012-02-12 20:09:41 EST

Sorry, was not on the nightly build. Working now in 
org.eclipse.zest.dot.core_2.0.0.201202102322.jar