Bug 317912 - 3.x RCP applications have to be updated before they can run in e4
Summary: 3.x RCP applications have to be updated before they can run in e4
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.1   Edit
Hardware: PC Windows XP
: P2 major (vote)
Target Milestone: 4.2   Edit
Assignee: Paul Webster CLA
QA Contact:
URL:
Whiteboard:
Keywords:
: 340477 370099 376565 (view as bug list)
Depends on: 341594
Blocks:
  Show dependency tree
 
Reported: 2010-06-25 01:58 EDT by Lars Vogel CLA
Modified: 2019-05-21 10:11 EDT (History)
18 users (show)

See Also:


Attachments
make rcp go v01 (212.37 KB, patch)
2010-07-09 14:59 EDT, Paul Webster CLA
no flags Details | Diff
Provide a default e4xmi for RCP apps (7.86 KB, patch)
2011-04-05 10:02 EDT, Paul Webster CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Lars Vogel CLA 2010-06-25 01:58:21 EDT
Currently the Eclipse 4.0 SDK does not allow to run standard Eclipse 3.6 RCP applications. Build ID: I20100623-1410. 

Create a new plugin project. Select RCP and select the "RCP with a view template". 

If you run it you receive:

org.eclipse.core.runtime.AssertionFailedException: null argument:applicationXMI argument missing
	at org.eclipse.core.runtime.Assert.isNotNull(Assert.java:85)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.loadApplicationModel(E4Application.java:216)
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:136)
	at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:528)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:521)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at testing.Application.start(Application.java:20)
	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:369)
	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:619)
	at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574)
	at org.eclipse.equinox.launcher.Main.run(Main.java:1407)
	at org.eclipse.equinox.launcher.Main.main(Main.java:1383)
Comment 1 Paul Webster CLA 2010-06-25 08:46:48 EDT
This is a side effect of the fact that the model we use is in our "product", in org.eclipse.platform, and that products now have to provide the applicationXMI and possibly the applicationCSS.

one possibility would be to move the LegacyIDE.xmi down into the workbench plugin, and refer to it from there.  It needs to be there before the workbench can use advisors to fill in the rest of the info (like the main menus).

But this is totally untested.  Our immediate goal is to get the 4.0 SDK up and running.

PW
Comment 2 Lars Vogel CLA 2010-06-28 13:16:27 EDT
this does not speak well for the compatibility story... I assume lots of people which would try e4 would try the old wizards, especially as the 4.0 SDK will not contain out-of-the box a e4 wizard (I believe Yves wizard will be an add on).

These people will experience very fast a failure. Would it be possible to disable the RCP template function if the 4.0 SDK cannot host them?
Comment 3 Thomas Schindl CLA 2010-07-01 07:57:50 EDT
What about the following idea. Use Fragment-Patching and overwrite the wizards with e4 specific one who generate the same in an e4 way? Probably this task is too big so for some of the Wizards we could at least open a Info-Box saying this wizard is not working in 4.0 SDK.

The other possibility is that we use http://wiki.eclipse.org/Equinox_Transforms but I'm not sure the state of this project.
Comment 4 Paul Webster CLA 2010-07-09 14:59:49 EDT
Created attachment 173898 [details]
make rcp go v01

This is what 15 minutes will get you.  I can create the RCP Mail plugin.  By moving the LegacyIDE.e4xmi file to org.eclipse.ui.workbench, it can be used as a default if one is not provided.

The problem is, of course, missing plugins if you try and launch from the PDEEditor:

org.eclipse.equinox.ds
org.eclipse.equinox.event
org.eclipse.e4.ui.workbench.addons.swt
+ their required plugins.

That was enough for it to launch and provide menus and toolbars.  The perspective is empty, however.

PW
Comment 5 Oleg Besedin CLA 2010-07-22 14:26:24 EDT
With the fix for the bug 320163 RCP mail with updated launch configuration mostly works.

The need to update the launch configuration or product file will be addressed in 4.1.

There are few other hickups:

- The RCP Mail app has "Quick Access" control in its toolbar
- Min/max looks different from 3.x verison
- Drag&Drop message view results in NPE if I drag a message view on the tree
view

Those are likely going to be fixed by general fixes, I am mentioning them here as a reminder.
Comment 6 Oleg Besedin CLA 2010-07-23 11:34:37 EDT
For completness, here are the current steps required to have wizard-generated RCP Mail app to work in e4:

1. Add the following to the product extension in the plugni.xml :

    <property name="applicationXMI" value="org.eclipse.platform/LegacyIDE.e4xmi"/>

2. Add the following bundles to the launch configuration:

org.eclipse.equinox.event
org.eclipse.equinox.ds
org.eclipse.e4.ui.workbench.addons.swt
org.eclipse.platform

and their required plugins.
Comment 7 Paul Webster CLA 2011-03-21 14:08:42 EDT
*** Bug 340477 has been marked as a duplicate of this bug. ***
Comment 8 Paul Webster CLA 2011-04-01 07:10:04 EDT
If LegacyIDE.e4xmi is needed as the "shell" to launch the workbench through PlatformUI.createAndRunWorkbench(*) then we should probably move LegacyIDE.e4xmi to org.eclipse.ui.workbench.  Then parse the incoming args, and if applicationXMI is not specified use ours.

PW
Comment 9 Lars Vogel CLA 2011-04-01 07:26:18 EDT
@Paul: that would be a great simplification +1
Comment 10 Paul Webster CLA 2011-04-05 10:02:59 EDT
Created attachment 192559 [details]
Provide a default e4xmi for RCP apps

This is a default e4xmi for RCP apps, so it no longer requires that an RCP app suddenly have to define a product or change its plugin.  If it does define a product, it will have to change that to include the new plugin lineup needed for e4.

But plugins still have to be added to the launch config, at least when compared to the defaults for the RCP Mail application generated from a template:

org.eclipse.e4.ui.workbench.addons.swt
org.eclipse.equinox.ds
org.eclipse.equinox.event
org.eclipse.equinox.util



PW
Comment 11 Brian de Alwis CLA 2011-04-07 17:29:21 EDT
(In reply to comment #10)
> But plugins still have to be added to the launch config, at least when compared
> to the defaults for the RCP Mail application generated from a template:

Could we include a p2.inf in the compatibility plugin to invoke the installBundle() touchpoint?

(Never tried this myself; there's an open bug for setting start levels though in bug 253244)
Comment 12 Paul Webster CLA 2011-04-12 10:21:04 EDT
(In reply to comment #10)
> Created attachment 192559 [details]
> Provide a default e4xmi for RCP apps

I've released this fix, so arguably you don't need to create a product to run your legacy RCP application.

If we want to provide some kind of conversion action that could work against a product or an internal launch config, we should work on it in bug 341594

PW
Comment 13 Lars Vogel CLA 2011-04-12 11:05:26 EDT
Thanks Paul, looks great. 

It looks to me that you always adding the legacy XMI, therefore removing the need to provide a own XMI file. Is this always correct? 

Mayby there are situations there I want to provide some elements via XMI and others via extension points?
Comment 14 Paul Webster CLA 2011-04-12 11:21:49 EDT
(In reply to comment #13)
> Thanks Paul, looks great. 
> 
> It looks to me that you always adding the legacy XMI, therefore removing the
> need to provide a own XMI file. Is this always correct? 

The problem I was trying to solve was "I have a 3.x RCP application that launches an application ... how do I run it on 4.x".  We used to make them provide a product and an e4xmi.  Now they could still run just an application that calls createAndRunWorkbench(*) like they used to.  They still must add the new plugins, though.

> Mayby there are situations there I want to provide some elements via XMI and
> others via extension points?

If they want more than above (i.e. they want to take advantage of even CSS) they have to start providing things like a product, the style sheets, pull in even more plugins, etc.

PW
Comment 15 Lars Vogel CLA 2011-04-12 13:39:20 EDT
Would the patch work if I have a product and do not specify a XMI? If yes, I think that would be great. People tend to have a product for Eclipse 3.X RCP applications as you require this to to the export and to manage the run config.
Comment 16 Paul Webster CLA 2011-04-12 13:59:40 EDT
(In reply to comment #15)
> Would the patch work if I have a product and do not specify a XMI? If yes, I
> think that would be great. 

Yes, this will work equally well for a 3.x RCP app that's only an app, or that has a product as well (but no 4.x components like the XMI)

PW
Comment 17 Kentaroh Noji CLA 2011-04-21 22:01:08 EDT
Error messages are different, but the same symptom happens in Eclipse v4.1.

Version: 4.1.0
Build id: I20110412-2200

Error messages: 
!SESSION 2011-04-22 10:58:40.956 -----------------------------------------------
eclipse.buildId=unknown
java.fullversion=JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64 jvmwa6460sr9-20110203_74623 (JIT enabled, AOT enabled)
J9VM - 20110203_074623
JIT  - r9_20101028_17488ifx3
GC   - 20101027_AA
BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en
Framework arguments:  -application RCP2.application
Command-line arguments:  -application RCP2.application -data C:\Users\knoji\workspace\41-0425/../runtime-RCP2.application -dev file:C:/Users/knoji/workspace/41-0425/.metadata/.plugins/org.eclipse.pde.core/RCP2.application/dev.properties -os win32 -ws win32 -arch x86_64 -consoleLog

!ENTRY org.eclipse.osgi 4 0 2011-04-22 10:58:42.282
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Core services not available. Please make sure that a declarative service implementation (such as the bundle 'org.eclipse.equinox.ds') is available!
	at org.eclipse.e4.ui.internal.workbench.swt.E4Application.createE4Workbench(E4Application.java:194)
	at org.eclipse.ui.internal.Workbench$3.run(Workbench.java:529)
	at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
	at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:522)
	at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
	at rcp2.Application.start(Application.java:20)
	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(NativeMethodAccessorImpl.java:60)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
	at java.lang.reflect.Method.invoke(Method.java:611)
	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)
Comment 18 Thomas Schindl CLA 2011-04-22 02:12:20 EDT
(In reply to comment #17)
> Error messages are different, but the same symptom happens in Eclipse v4.1.
> 
> Version: 4.1.0
> Build id: I20110412-2200
> 
> Error messages: 
> !SESSION 2011-04-22 10:58:40.956
> -----------------------------------------------
> eclipse.buildId=unknown
> java.fullversion=JRE 1.6.0 IBM J9 2.4 Windows 7 amd64-64
> jvmwa6460sr9-20110203_74623 (JIT enabled, AOT enabled)
> J9VM - 20110203_074623
> JIT  - r9_20101028_17488ifx3
> GC   - 20101027_AA
> BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en
> Framework arguments:  -application RCP2.application
> Command-line arguments:  -application RCP2.application -data
> C:\Users\knoji\workspace\41-0425/../runtime-RCP2.application -dev
> file:C:/Users/knoji/workspace/41-0425/.metadata/.plugins/org.eclipse.pde.core/RCP2.application/dev.properties
> -os win32 -ws win32 -arch x86_64 -consoleLog
> 
> !ENTRY org.eclipse.osgi 4 0 2011-04-22 10:58:42.282
> !MESSAGE Application error
> !STACK 1
> java.lang.IllegalStateException: Core services not available. Please make sure
> that a declarative service implementation (such as the bundle
> 'org.eclipse.equinox.ds') is available!

So did you add the required ds bundle to your launch configuration as the error message suggests?
Comment 19 Paul Webster CLA 2012-01-30 08:35:26 EST
*** Bug 370099 has been marked as a duplicate of this bug. ***
Comment 20 Paul Webster CLA 2012-04-12 07:38:53 EDT
*** Bug 376565 has been marked as a duplicate of this bug. ***
Comment 21 Lars Vogel CLA 2012-09-18 14:26:48 EDT
Just tested, with a brand new Eclipse 3.X RCP app. Seems to work fine in Eclipse 4.2 to run this application without any additonal steps. And we have modified the org.eclipse.rcp feature.

Closing therefore as fixed.
Comment 22 Lars Vogel CLA 2012-09-18 14:27:12 EDT
Status changed.
Comment 23 J. Matt Casson CLA 2013-07-26 16:10:29 EDT
I am still getting the NPE in ModelServiceImpl (line 124) using eclipse 4.3.  The NPE is occurring on the same line as outline in bug 370099 which was closed as a duplicate of this one.  Line 124 in the 4.3 version is the same line as 92 in the 4.2 version.

Now this is happening in our own application and only when I run it using web start, so it may be something else.  Should I write it up seperately?
Comment 24 Paul Webster CLA 2013-07-29 13:55:08 EDT
(In reply to comment #23)
> I am still getting the NPE in ModelServiceImpl (line 124) using eclipse 4.3.
> The NPE is occurring on the same line as outline in bug 370099 which was
> closed as a duplicate of this one.  Line 124 in the 4.3 version is the same
> line as 92 in the 4.2 version.
> 
> Now this is happening in our own application and only when I run it using
> web start, so it may be something else.  Should I write it up seperately?

Please open a new bug.  Keep an eye out that the extra bundles mentioned from comment #10 are being started at the correct time by your webstart.

PW
Comment 25 J. Matt Casson CLA 2013-08-14 14:53:17 EDT
(In reply to comment #24)
> (In reply to comment #23)
> > I am still getting the NPE in ModelServiceImpl (line 124) using eclipse 4.3.
> > The NPE is occurring on the same line as outline in bug 370099 which was
> > closed as a duplicate of this one.  Line 124 in the 4.3 version is the same
> > line as 92 in the 4.2 version.
> > 
> > Now this is happening in our own application and only when I run it using
> > web start, so it may be something else.  Should I write it up seperately?
> 
> Please open a new bug.  Keep an eye out that the extra bundles mentioned
> from comment #10 are being started at the correct time by your webstart.
> 
> PW

It was an issue with the OSGI bundles not getting properly started when using web start.  I'm not sure where they get lost between creating the feature from the product (which has them specified), then bundling them for web start.  But once I included the osgi.bundles property with the needed items (as suggested in comment #10), there were no other issues.

Thanks.