| Rayo versions [message #1011750] |
Wed, 20 February 2013 02:40  |
Eclipse User |
|
|
|
I have installed the current Scout EPP Version: eclipse-scout-juno-SR1 (Version 3.8.1.201209171521)
I have installed RAYO with the Technology box in the scout perspective, and got com.bsiag.scout.rt.ui.swing.rayo (Version 3.8.2.201301081210)
Now I have this exception:
!ENTRY org.eclipse.scout.rt.ui.swing 2 0 2013-02-20 07:47:49.751
!MESSAGE org.eclipse.scout.rt.ui.swing.AbstractSwingApplication.<init>(AbstractSwingApplication.java:95) null
!STACK 0
java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1055)
at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1326)
at org.eclipse.scout.rt.ui.swing.AbstractSwingApplication.<init>(AbstractSwingApplication.java:85)
at minifigcreator.ui.swing.SwingApplication.<init>(SwingApplication.java:29)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:184)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:191)
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:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Caused by: java.lang.NoSuchMethodError: org.eclipse.scout.rt.ui.swing.SwingUtility.hasScoutLookAndFeelFrameAndDialog()Z
at com.bsiag.scout.rt.ui.swing.laf.rayo.Rayo.installLookAndFeel(Rayo.java:59)
at org.eclipse.scout.rt.ui.swing.inject.InitLookAndFeelInjector.initScoutLAF(InitLookAndFeelInjector.java:89)
at org.eclipse.scout.rt.ui.swing.inject.InitLookAndFeelInjector.inject(InitLookAndFeelInjector.java:38)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.initLookAndFeel(AbstractSwingEnvironment.java:161)
at com.bsiag.scout.rt.ui.swing.rayo.RayoSwingEnvironment.initLookAndFeel(RayoSwingEnvironment.java:79)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.init(AbstractSwingEnvironment.java:143)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.<init>(AbstractSwingEnvironment.java:130)
at com.bsiag.scout.rt.ui.swing.rayo.RayoSwingEnvironment.<init>(RayoSwingEnvironment.java:63)
at minifigcreator.ui.swing.SwingEnvironment.<init>(SwingEnvironment.java:14)
at minifigcreator.ui.swing.SwingApplication.createSwingEnvironment(SwingApplication.java:46)
at org.eclipse.scout.rt.ui.swing.AbstractSwingApplication$1.run(AbstractSwingApplication.java:89)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:607)
at java.awt.EventQueue$1.run(EventQueue.java:605)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
Root exception:
java.lang.NoSuchMethodError: org.eclipse.scout.rt.ui.swing.SwingUtility.hasScoutLookAndFeelFrameAndDialog()Z
at com.bsiag.scout.rt.ui.swing.laf.rayo.Rayo.installLookAndFeel(Rayo.java:59)
at org.eclipse.scout.rt.ui.swing.inject.InitLookAndFeelInjector.initScoutLAF(InitLookAndFeelInjector.java:89)
at org.eclipse.scout.rt.ui.swing.inject.InitLookAndFeelInjector.inject(InitLookAndFeelInjector.java:38)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.initLookAndFeel(AbstractSwingEnvironment.java:161)
at com.bsiag.scout.rt.ui.swing.rayo.RayoSwingEnvironment.initLookAndFeel(RayoSwingEnvironment.java:79)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.init(AbstractSwingEnvironment.java:143)
at org.eclipse.scout.rt.ui.swing.AbstractSwingEnvironment.<init>(AbstractSwingEnvironment.java:130)
at com.bsiag.scout.rt.ui.swing.rayo.RayoSwingEnvironment.<init>(RayoSwingEnvironment.java:63)
at minifigcreator.ui.swing.SwingEnvironment.<init>(SwingEnvironment.java:14)
at minifigcreator.ui.swing.SwingApplication.createSwingEnvironment(SwingApplication.java:46)
at org.eclipse.scout.rt.ui.swing.AbstractSwingApplication$1.run(AbstractSwingApplication.java:89)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:199)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:646)
at java.awt.EventQueue.access$000(EventQueue.java:84)
at java.awt.EventQueue$1.run(EventQueue.java:607)
at java.awt.EventQueue$1.run(EventQueue.java:605)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:616)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:269)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:184)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:174)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:169)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:161)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:122)
I think that this is because swing rayo 3.8.2 requires org.eclipse.scout.rt.ui.swing 3.8.2 (this version contains the missing method. See source: SwingUtility.java)
How can I fix this somewhere (without updating to 3.8.2)?
Why did the SDK install the wrong version? Is this a known bug?
The Rayo Update site ( http://tools.bsiag.com/marketplace/rayo/3.8 ) seems to provide older versions. Are they installed?
It is allowed in the version 3.8.2 of Rayo to requires a org.eclipse.scout.rt.ui.swing 3.8.2?
==> OSGi versions are called semantic because they have meaning. See: SemanticVersioning.pdf (OSGi Alliance)
|
|
|
|
|
|
|
| Re: Rayo versions [message #1013498 is a reply to message #1013023] |
Sat, 23 February 2013 15:19  |
| Eclipse User |
|
|
|
Hi all
Quote:
We should also talk about API changes / extensions within a SR release. In my opinion if an API is extended for an upcoming SR, other products (like our Marketplace products) should not use this API if they are targeted for the same SR release.
If we switch to a new major release (e.g. Scout 3.9), the new API can be used of course.
Incompatibility of Scout bundles between different service releases (in OSGi terms: increasing the micro part of the version) does also affect the Scout core bundles itself. For example scout.rt.client 3.8.1 requires at minimum scout.rt.shared 3.8.1 and is not compatible with scout.rt.shared 3.8.0. See related forum thread: http://www.eclipse.org/forums/index.php/t/456019
While semantic versions of OSGi bundles (as described in the link provided by Jérémie) seems to be a nice concept, I don't think that it is practical for the Scout project, especially if the version numbers are dictated by the Eclipse release train.
Following OSGi semantic versions, you wouldn't even be allowed to introduce a new API method in a new service release (as it breaks the API for implementers)! And it would mean that e.g. scout.rt.client 3.8.x must compile against all versions of scout.rt.shared >= 3.8.0. Personally, I think this is too restrictive. The basic bundles (such as scout.rt.shared or scout.commons) should be allowed to provide new API methods, dependent bundles (such as scout.rt.client or scout.rt.server) should be allowed to profit from them, also within a service release. It would mean that the Scout bundles are only guaranteed to be compatible against each other within the same micro version, but not necessarily within the same minor version. Or in other words: if you switch to a new service release, you must update all Scout bundles to the same service release.
Also, following OSGi semantic versions, it would not be allowed to break the API for existing consumers with a new minor release (e.g. going from 3.8 to 3.9). But I think this is common practice in the Scout project, as you usually have a migration guide when changing from one minor version to the next.
I think it would help if the Scout project clearly defined its versioning and compatibility policy, which need not necessarily be OSGi semantic versions. But the chosen compatibility policy should also be reflected in the manifest files of the respective bundles (i.e. defining the correct version range of a required bundle).
Quote:
It is allowed in the version 3.8.2 of Rayo to requires a org.eclipse.scout.rt.ui.swing 3.8.2?
So, yes, in my opinion, you should be allowed to use the new API method and bump the version of the required bundle. I would prefer this approach over "inlining" (meaning: copy) the method from the required bundle. It might be justified in this specific case (I don't know the code), but in general, this is certainly a bad idea.
Just my two cents 
Lukas
|
|
|
| Re: Rayo versions [message #1014873 is a reply to message #1013498] |
Tue, 26 February 2013 11:11 |
| Eclipse User |
|
|
|
Hi Lukas,
Thanks for your helpful input.
Quote:
...
Personally, I think this is too restrictive. The basic bundles (such as scout.rt.shared or scout.commons) should be allowed to provide new API methods, dependent bundles (such as scout.rt.client or scout.rt.server) should be allowed to profit from them, also within a service release. It would mean that the Scout bundles are only guaranteed to be compatible against each other within the same micro version, but not necessarily within the same minor version. Or in other words: if you switch to a new service release, you must update all Scout bundles to the same service release.
I agree that the OSGI semantic versioning is too restrictive for Scout. I also acknowledge that an API change inside the bundle scout.commons should be used for example by font=Courier]scout.rt.client[/font] or scout.rt.server within a minor release as long as they belong to the same feature. Currently (Scout 3.9 Nightly Updatesite), we have the following important features:
- Scout Runtime
- Scout Runtime RAP
- Scout Runtime RAP Testing
- Scout Runtime Testing
- Scout SDK
- Scout SDK RAP
Additionally, there are features for JDBC and Rayo (Marketplace). My proposal is to allow consuming API changes within bundles that are located in the same feature but using changed APIs of a bundle in a different feature is prohibited.
E.g. In Scout Runtime version 3.8.2 a new method in SwingUtility was added that was used in Rayo 3.8.2. Since SwingUtility is not part of the Rayo feature, it's prohibited for the Rayo bundle to call that method.
What do you think about that?
Quote:
Also, following OSGi semantic versions, it would not be allowed to break the API for existing consumers with a new minor release (e.g. going from 3.8 to 3.9). But I think this is common practice in the Scout project, as you usually have a migration guide when changing from one minor version to the next.
I absolutely agree that introduced API changes within a SR release are allowed to be consumed in the upcoming major release.
|
|
|
|
| Re: Rayo versions [message #1014923 is a reply to message #1014873] |
Tue, 26 February 2013 14:59 |
| Eclipse User |
|
|
|
I just read this blog article: API Tools revisited => API Compatibility Check
I think that scout contributor/commiter should use this feature to force "@since" tags on new methods. I do not know how the checks works, but it would probably help to identify API violations.
|
|
|
Powered by
FUDForum. Page generated in 0.04715 seconds
Home