Community
Participate
Working Groups
Given an editor for a multi-package model such as OCLinEcore in which the OCLinEcoreCST package defines a concrete type that refines an abstract type in the BaseCST package, the installation of proxies discovers that the type in the BaseCST package is abstract and so searches for a concrete sub-type. No problem. But, with the concrete sub-type in another package, LazyLinker.findInstantiableCompatible searches all possible URIs and eventually finds the package from which the editor was derived in the first place. a) this is very inefficient b) because of Bug 320417 whereby EMF wraps a CNFE when loading a class-less JST EPackage registration, the search is terminated before the required package is found; editor initialization gives a very obscure message. b) the loop should catch a WrappedException a) local packages should be searched first ? should global packages be search at all? Effectively this means that Xtext and JST are incompatible.
Besides the suggestions, we should provide a hook that allows to define the packages that should be searched first. What are local packages?
Minimal local: the current packages (imported by the editor grammar) Inherited local: the packages of the transitive closure of the inheritance of the classes in the current packages Maximal local: the packages of the transitive closure of the references of the classes in the current packages I suspect that "Inherited local" is enough for this problem, but there seems no justification going beyond "Maximal local" except when doing a Content Assist/Quick Fix and even then I think there should be a click-through to authorize loading all packages (which is much more costly and less well-behaved than loading all Java classes).
*** Bug 321432 has been marked as a duplicate of this bug. ***
Fixed in HEAD. See LazyLinker#globalFindInstantiableCompatible for details.
Closing bug which were set to RESOLVED before Eclipse Neon.0.
