Community
Participate
Working Groups
Build Identifier: Starting the org.eclipse.sphinx.emf.validation.bridge plugin currently trigger a start to all model plugins that the contributors to the org.eclipse.sphinx.emf.validation.registration extension point are referring. This is triggered in two different places: 1: Inside RulesExtReader#readElement(...) method the NsURI of the EMF package refered by the contribution is retrieved from registry which trigger a start of the plugin implementing the model. I suggest to do ePackageWrapper = EPackage.Registry.INSTANCE.get(tgt.getNsURI().toString()); instead of ePackage = EPackage.Registry.INSTANCE.getEPackage(tgt.getNsURI().toString()) The first version will return either the EPackage or the EPackage.Descriptor, it should be enough to check the presence of the package. 2: Inside RulesExtCache#addExtension(IExtension) There is an explicit call to load the bundle that contributed to the org.eclipse.sphinx.emf.validation.registration extension. I don't know why this is needed, if it really is, but temporary disabling it showed no impact on the application. Additionally, if starting with an empty workspace, with the above mentioned changes applied going to "Preferences\Model Validation\Constraints" trigger a load of contributed models even if all the information present lays only inside plugin.xml files. So there shouldn't be a reason to start the plugins. But I'm not sure if this is because of the Sphinx plugin or of the EMF Validation plugin. Reproducible: Always
(In reply to comment #0) > Starting the org.eclipse.sphinx.emf.validation.bridge plugin currently trigger a > start to all model plugins that the contributors to the > org.eclipse.sphinx.emf.validation.registration extension point are referring. I'm fully aware of that and agree that this is a very ugly kind of approach. It btw. is the reason why the progress bar which is displayed when starting a runtime workbench on a Sphinx workspace stops approx. in the middle and continues after a little while only. > This is triggered in two different places: > > 1: Inside RulesExtReader#readElement(...) method the NsURI of the EMF package > refered by the contribution is retrieved from registry which trigger a start of > the plugin implementing the model. I suggest to do > ePackageWrapper = EPackage.Registry.INSTANCE.get(tgt.getNsURI().toString()); > instead of > ePackage = EPackage.Registry.INSTANCE.getEPackage(tgt.getNsURI().toString()) > The first version will return either the EPackage or the EPackage.Descriptor, it > should be enough to check the presence of the package. Agreed. > 2: Inside RulesExtCache#addExtension(IExtension) > There is an explicit call to load the bundle that contributed to the > org.eclipse.sphinx.emf.validation.registration extension. I don't know why this > is needed, if it really is, but temporary disabling it showed no impact on the > application. I have to admit that I also don't know the reason for the explicit contributor bundle loading approach. I agree with removing it. It clearly violates the good old Eclipse lazy loading house rule. If ever we should encounter side effects because of that later on then we can reopen this bug and think of a better solution than the current implementation for getting around this side effect.
Created attachment 191688 [details] Patch Patch attached
Fixed by applying proposed patch.
Mass-closing Resolved tickets
