Bugzilla – Full Text Bug Listing
| Summary: | [releng] review dependency lower and upper bounds | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Ed Willink <ed> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | adolfosbh |
| Version: | 3.1.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
|
Description
Ed Willink
I'm currently writing some (long) conclusions about plugin dependencies (and versions) on the Bug 335459 which are very related to this bug (which expands the Bug 335459 to every MDT/OCL plugin rather than just examples plugins). Cheers, Adolfo. (In reply to comment #0) > e4 has a good compatibility layer, so we should check functionality and make > sure that platform 4.x is in bounds. I just did an install of 3.6 OCL Examples on 4.1M6. Installed without any problem so clearly the 4.0 upper bound is being worked around. Editor and Console started ok; editor looks a bit white at the left; SWT style I suppose. One minor funny, OCLinEcore editor saved as text not XMI. Otherwise it seems it probably just all works. Ed, (In reply to comment #0) > ocl.ecore implements the EMF 2.7 QueryDelegate interface but has a 2.6 lower > bound. Is this allowed? If so shouldn't we lower bounds further to also not > require the 2.6 InvocationDelegates. If not must fix. I don't follow you when you say "has a 2.6 lower bound". o.e.ocl.ecore depends on o.e.ocl which depends on EMF 2.7... > > If the new code is runnable on EMF 2.6, then some clumsy default Indigo lower > bounds on recent examples plugins should be lowered. > Currently, MDT/OCL 3.1.0 can't be installed in an Helios + EMF 2.6 installation because org.eclipse.ocl depends on org.eclipse.emf.ecore 2.7. > e4 has a good compatibility layer, so we should check functionality and make > sure that platform 4.x is in bounds. Concerning the maximum version range I've heard that you have tested the code on Eclipse 4.1... Do you want to try it this for Indigo release and make the correspondent changes ?. I could try to create a target platform using Eclipse 4.1 SDK, and to change dependencies to see what happens. Cheers, Adolfo. (In reply to comment #3) > I don't follow you when you say "has a 2.6 lower bound". o.e.ocl.ecore depends > on o.e.ocl which depends on EMF 2.7... Ok. That explains it, it got raised to the common mimimum. > > > > If the new code is runnable on EMF 2.6, then some clumsy default Indigo lower > > bounds on recent examples plugins should be lowered. > > > > Currently, MDT/OCL 3.1.0 can't be installed in an Helios + EMF 2.6 installation > because org.eclipse.ocl depends on org.eclipse.emf.ecore 2.7. Yes. But the editors can, because the editors do not directly use any of the core ocl plugins. Indirectly they do via examples.common, but that allows OCL 3.0, so the editors could be ok (3.1 editors plugins; 3.1 or 3.0 examples common, 3.0 core plugins.) Ditto, the impact analyzer could be runnable on Helios. I tried an experiment using the 3.6.1 modeling distribution and 3.7M7 update site ZIPs. P2 could install MWE+XPAND+XTEXT with no difficulty. But OCL Examples (no Extender) fails because the EventManager 'needs' EMF 2.7; it doesn't - the manifest entry is blank, which in our build causes a pretty strict [2.7.0,3.0.0) to appear in the content.xml. However similar blankness in for instance the org.eclipse.xtext.common.types manifest are translated to 0.0.0 in the Xtext content.xml. I suspect that there is a Buckminster option to select the generous Xtext behaviour rather than our strict behaviour. I think we should use it if we can. > > Yes. But the editors can, because the editors do not directly use any of the > core ocl plugins. Indirectly they do via examples.common, but that allows OCL > 3.0, so the editors could be ok (3.1 editors plugins; 3.1 or 3.0 examples > common, 3.0 core plugins.) Ditto, the impact analyzer could be runnable on > Helios. > So, indirectly (via o.e.o.examples.common -> o.e.ocl.ecore -> o.e.ocl) they would require EMF 2.7, am I missing anything?... unless you may want to make the editors work with MDT/OCL Core 3.0.0, which would be quite weird BTW ;P. Impact Analyzer needs a lot of stuff from MDT/OCL Core 3.1.0 so I don't think that it works in an Helios installation. > I tried an experiment using the 3.6.1 modeling distribution and 3.7M7 update > site ZIPs. P2 could install MWE+XPAND+XTEXT with no difficulty. But OCL Examples > (no Extender) fails because the EventManager 'needs' EMF 2.7; it doesn't - the > manifest entry is blank, which in our build causes a pretty strict [2.7.0,3.0.0) > to appear in the content.xml. > Yes, I explained that in the Bug 335459 coment 3 (paragraph 4): > However similar blankness in for instance the org.eclipse.xtext.common.types > manifest are translated to 0.0.0 in the Xtext content.xml. > > I suspect that there is a Buckminster option to select the generous Xtext > behaviour rather than our strict behaviour. I think we should use it if we can. I'm not sure if you are talking about features or plugin dependencies, anyway... I think that our approach is the good one. Otherwise, somebody could try to install the components in an environment in which they really don't work (let's say EMF 2.4, for instance). Buckminster assumes that the minimum required environment, in which a generated-by-buckminster component works, is the target environment that said component was compiled against. Therefore the blank dependency turns into [2.7.0, 3.0.0) Again, the discussion needs to know if we want to provide backwards compatibility, a) If we don't provide such backwards compatibility: 1) I'm inclined to use blankness in our plugin dependencies -> Every MDT/OCL release will only be installable in the correspondent yearly distributed Eclipse Modeling Package (and probably in future releases, depending on the major version increment done by the projects on which we depend) b) If we provide any backwards compatibility 1) We should rather use version range match on our dependencies. 2) We should find out and set the real minimum version range of our dependencies. 3) We should test that our components really work in previous releases. 4) In future releases, we should be careful when using new API of the projects on which we depend on, so that either we control the runtime environment to avoid runtime crashes (as Acceleo does) or we update the version of our backwards compatibility support. I'm not sure if this discussion could be scaled up to obtain more feedback from other folks.... Anyway, as commented at the other bugzilla, backwards compatibility is cool, but the cost to facilitate such a compatibility and providing that nobody has asked for the enhancement, I'm inclined to no providing any compatibility at all, because it will imply more inconveniences than advantages. Cheers, Adolfo. Experiments concerning Eclipse 4. I've easily compiled and executed my workspace against an Eclipse 4.1M5 SDK + Xtext SDK target platform. On the one hand I've successfully opened the OCLInEcore editor using an Empty ecore file. We could say that we (and the components on which we depend) are OK with Eclipse 4.1 and its backward compatibility layer. We wouldn't need any dependencies version match change, since we still depend on platform 3.x components which work in Eclipse 4.1 platform by the means of the compatibility layer. On the other hand creating the Loyal and Royal example throws an exception [1]. We have an incompatibility issue here... Best Regards, Adolfo. [1] The exception: java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:421) at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1029) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard.performFinish(AbstractExampleWizard.java:127) at org.eclipse.ui.internal.dialogs.NewWizard.performFinish(NewWizard.java:134) at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:827) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:432) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:624) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:240) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4150) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3739) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ui.internal.handlers.WizardHandler$New.executeHandler(WizardHandler.java:254) at org.eclipse.ui.internal.handlers.WizardHandler.execute(WizardHandler.java:274) at org.eclipse.ui.internal.handlers.HandlerProxy.execute(HandlerProxy.java:293) at org.eclipse.ui.internal.handlers.E4HandlerProxy.execute(E4HandlerProxy.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.e4.core.internal.di.MethodRequestor.execute(MethodRequestor.java:56) at org.eclipse.e4.core.internal.di.InjectorImpl.invokeUsingClass(InjectorImpl.java:226) at org.eclipse.e4.core.internal.di.InjectorImpl.invoke(InjectorImpl.java:207) at org.eclipse.e4.core.contexts.ContextInjectionFactory.invoke(ContextInjectionFactory.java:123) at org.eclipse.e4.core.commands.internal.HandlerServiceImpl.executeHandler(HandlerServiceImpl.java:122) at org.eclipse.ui.internal.handlers.LegacyHandlerService.executeCommand(LegacyHandlerService.java:365) at org.eclipse.ui.internal.actions.CommandAction.runWithEvent(CommandAction.java:157) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4150) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3739) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$7.run(PartRenderingEngine.java:852) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:768) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:87) at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:542) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:524) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:123) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:344) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:622) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:577) at org.eclipse.equinox.launcher.Main.run(Main.java:1410) at org.eclipse.equinox.launcher.Main.main(Main.java:1386) Caused by: java.lang.NullPointerException at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard.unzipProject(AbstractExampleWizard.java:191) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard.access$0(AbstractExampleWizard.java:174) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard$1$1.execute(AbstractExampleWizard.java:138) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2310) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard$1.run(AbstractExampleWizard.java:143) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) Root exception: java.lang.NullPointerException at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard.unzipProject(AbstractExampleWizard.java:191) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard.access$0(AbstractExampleWizard.java:174) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard$1$1.execute(AbstractExampleWizard.java:138) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:106) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2310) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:118) at org.eclipse.ocl.examples.internal.wizard.AbstractExampleWizard$1.run(AbstractExampleWizard.java:143) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121) The root exception is an NPE on interpreterZipUrl computed by: URL interpreterZipUrl = FileLocator.find(Platform.getBundle(bundleName), new Path(zipLocation), null); this has three distinct platform calls to investigate. Will you investigate? Sure. Tomorrow, I'll have a look at it. Cheers, Adolfo. Ed, Ok, I've found the problem. In the second instance, the examples plugin doesn't contain the zipped examples, my fault ;P I've checked that all works fine in a Eclipse 4.1 SDK + Xtext SDK + OCL Examples (nightly). Another experiment it could be interesting investigating Eclipse 4.x API to know if it may replace the Eclipse 3.x one, so that we could be a pure Eclipse 4.x component... Anyway, this is not the moment to do it, and we won't probably make such a decision ;P Cheers, Adolfo. Ok. So as far as you are aware there are no known faults for 4.1. The planning council is urging 4.2 as primary and 3.8 as secondary, so after Indigo, I think we switch to 4.2 and GIT. The 4.2 changes are largely in the plugin registrations which mainly affect UI work, which for us is mainly Xtext anyway; Xtext is not inherently e4 yet. Only the Console has real contributions and that may get a major restructuring. Resolving the bug as fixed since the dependencies version ranges have been reviewed and committed in the context of the bug 335459 CLOSED after a year in the RESOLVED state. |