eclipse-qvt-oml-bot
commented
1 week ago By Ed Willink on May 25, 2021 05:53
Standalone, everything is on the one classpath so loading is not an issue except that dynamically created classes may be too-late and so need a custom loader that defers back to the standard.
Within Eclipse, each plugin has its own class loader seeing only its own classes. It is therefore necessary for shared tooling to use an outer/user/test class rather than the inner classpath of e.g. org.eclipse.emf.ecore. The Resource's class loader is often a good choice since the Resource was created by the user/test harness. Sometimes it is necessary to allow the outer code to pass in a class loader.
I'm not sure that I really understand the problem. A good/bad example might help.
| --- | --- | | Bugzilla Link | 573752 | | Status | NEW | | Importance | P3 normal | | Reported | May 25, 2021 05:28 EDT | | Modified | Jun 07, 2021 16:13 EDT | | See also | Gerrit change 180968, Gerrit change 181158, Gerrit change 181512, Gerrit change 181513, Git commit 5544a0c3, Git commit b467ff0a, Gerrit change 181541 | | Reporter | Christopher Gerking |
Description
Another shortcoming of bug 472482 is that classes from bundles are not correctly recognized as blackbox classes, so that blackboxes based on these classes cannot be resolved successfully. This is because ProjectClassLoader will reload all classes instead of reusing the classes already loaded by the bundles' class loaders. Obviously, the reloaded classes are different from those obtained from the corresponding EPackage.Registry, which causes the bug.
Why does the problem not occur during the tests? Well, because these are based on Ecore. Since QVTo depends on EMF, the Ecore classes can be loaded by ProjectClassLoader.class.getClassLoader(), which is used as a parent class loader. However this does not work for arbitrary user-defined metamodels.
A possible solution would be to use the class loaders of required bundles as a composite parent loader. But this is likely to cause the same performance bottlenecks that we have already experienced for bug 571406. Is there another way to create a class loader against a given EPackage.Registry?