Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » scout » Rayo versions(Scout 3.8.1 and Rayo 3.8.2)
Rayo versions [message #1011750] Wed, 20 February 2013 02:40 Go to next message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 675
Registered: October 2011
Senior Member
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 #1012509 is a reply to message #1011750] Thu, 21 February 2013 12:29 Go to previous messageGo to next message
Ken Lee is currently offline Ken Lee
Messages: 97
Registered: March 2012
Member
Hi Jérémie,

Thanks for the input.
For the upcoming Scout EPP Version 3.8.2 (based on Eclipse Juno SR2), we provided a new Rayo build version 3.8.2 at the Marketplace which has been linked in the in [1]. This version uses a call to SwingUtility.hasScoutLookAndFeelFrameAndDialog() to check whether Rayo look and feel borders or native borders of the OS should be used.
This method has been introduced in Scout runtime 3.8.2.
Since the Rayo feature has a dependency to org.eclipse.scout.rt.feature, the version constraint needs to be incremented to 3.8.2 (currently, the Rayo feature does already have a dependency to org.eclipse.scout.rt.feature >=3.8.0)

I guess it shouldn't be a problem to enforce Rayo 3.8.2 to require Scout runtime 3.8.2.

[1] http://tools.bsiag.com/marketplace/rayo/3.8
Re: Rayo versions [message #1012745 is a reply to message #1012509] Fri, 22 February 2013 02:05 Go to previous messageGo to next message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 675
Registered: October 2011
Senior Member
I did an update of Scout to version 3.8.2 (using http://download.eclipse.org/scout/releases/3.8/3.8.2/ ) and as expected it works.

My Question is: what can we do to prevent such a case in future.

[Updated on: Fri, 22 February 2013 02:06]

Report message to a moderator

Re: Rayo versions [message #1013021 is a reply to message #1012745] Fri, 22 February 2013 11:10 Go to previous messageGo to next message
Ken Lee is currently offline Ken Lee
Messages: 97
Registered: March 2012
Member
In my previous post I was hoping that setting the version constraint 3.8.2 to org.eclipse.scout.rt.feature would also have an impact to the p2 installer such that the latest compatible version would be chosen.
Unfortunately, this is not the case. Since Rayo should be compatible with all Scout runtime version 3.8, we decided to provide a new Rayo build where the call to the previous mentioned method has been inlined.

I installed the latest Rayo 3.8.2 build into a Scout Juno SR1 EPP which worked as expected.

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.

What are your opinion?

Re: Rayo versions [message #1013023 is a reply to message #1013021] Fri, 22 February 2013 11:12 Go to previous messageGo to next message
Matthias Villiger is currently offline Matthias Villiger
Messages: 78
Registered: September 2011
Member
Hi Ken,

I agree Smile

regards,
m
Re: Rayo versions [message #1013498 is a reply to message #1013023] Sat, 23 February 2013 15:19 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas Huser
Messages: 41
Registered: March 2010
Member
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 Smile
Lukas
Re: Rayo versions [message #1014873 is a reply to message #1013498] Tue, 26 February 2013 11:11 Go to previous messageGo to next message
Ken Lee is currently offline Ken Lee
Messages: 97
Registered: March 2012
Member
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 #1014922 is a reply to message #1014873] Tue, 26 February 2013 14:49 Go to previous messageGo to next message
Lukas Huser is currently offline Lukas Huser
Messages: 41
Registered: March 2010
Member
Hi Ken

Thanks for your explanation. Your proposition makes sense to me, I didn't thought about the different features that are provided within the Scout project.

And it would be great if the different Scout bundles state the correct minimum version for required bundles in their manifest. I think this is currently not the case for some (most?) bundles, but it certainly could help if you happen to mix some bundles of different versions in your workspace.


Greetings Lukas
Re: Rayo versions [message #1014923 is a reply to message #1014873] Tue, 26 February 2013 14:59 Go to previous message
Jeremie Bresson is currently offline Jeremie Bresson
Messages: 117
Registered: November 2010
Senior Member
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.

Previous Topic:deployment problem
Next Topic:Eclipse Scout Maven Tycho Build
Goto Forum:
  


Current Time: Fri Aug 29 20:32:58 EDT 2014

Powered by FUDForum. Page generated in 0.02488 seconds