Home » Eclipse Projects » Eclipse 4 » to migrate or not to migrate?
|to migrate or not to migrate? [message #1142373]
||Thu, 17 October 2013 11:28
| SlowStrider Mising name
Registered: July 2009
Using Eclipse RCP 3.7 we've developed an ERP/reservation system with a calendar view and editors for events, customers and products. It could be released in about one month, but before releasing I would like to update our dependencies to the latest versions.|
I am stuck on what to do with the Eclipse RCP platform!
I love the concept of DI (in fact I already use it a lot using Spring-DM), but it seems that many features that are in Eclipse 3.x are not available in a pure E4 application. I definitely don't want to have to write code for existing functionality that I use from 3.x.
My big question is: what is the status of E4? Should I port to E4? If so how much effort would it take?
My own feeling at the moment is: stick to the 3.x model and release the application. In the meantime isolate new application code from Eclipse API as much as possible (using DI). Wait a year or so until E4 has matured and more of the old features used are ported.
When sticking to 3.x, should I keep using 3.7, should I upgrade to 3.8 or should I download the latest (4.3) and use the compatibility layer?
What is the advantage of using the compatibility layer over 3.8?
|Re: to migrate or not to migrate? [message #1142677 is a reply to message #1142374]
||Thu, 17 October 2013 15:51
| Christophe Bouhier
Registered: July 2009
I just went a similar "migration" with Eclipse 3.7 RCP with features like:
- console, outline, property, help, progress, ide, preferences, memmento
- a lot of ui.forms
- and much more...
(But not team, jdt, ltk)
I made a target which would build the RCP app against the kepler
download. Besides a few minor issues, it just works with the e4 compat
layer. You don't need to define an e4xmi or do any DI or what so ever.
It just works in the same way as the 4.3 Eclipse IDE with all the
classic views (and many more extensions) just work with the e4 workbench.
The minor issues (I reported them on the forum).
- The Intro Action stopped working (Just removed it).
- Standalone View drag/drop
- Make sure you use the e4 RCP and start the necessary plugins in the
Now, I think this is the best starting point for e4 if you have a rather
larger 3.x RCP with many classic extensions (Views, Perspectives etc..).
The reasons are:
- You are not left behind, the transition to e4 compat is super smooth.
- If you include the e4 live editor you can actually see your app
modelled with EMF and see how the compat layer does a transition.
- You can gradually move over stuff, when Luna comes out and latter on
(At least that's what I hear and read) , the mix mode will get more
attention so you can probably start to contribute the workbench model
with your own e4 stuff like fragments.
- The size increase of the RCP app is minimal, about < 10 Megabytes
extra, which I still need to optimize a bit. (See also my posts on
- This is 2 days work max. You will likely get results sooner.
I favor this method over pure e4 and then basically forced to reduce the
extend of the app, as so many things are just not working in pure e4
I really convinced this is the way to go, I hope others can share their
experience as well.
Oh and as a bonus you get a nice search entry box to find whatever you
need , which wasn't present in 3.7 :-)
So don't hesitate, compile your RCP against Kepler and enjoy the future.
Cheers ! Christophe
On 17-10-13 17:28, SlowStrider Mising name wrote:
> More details of my situation:
> Apart from using SWT/JFace, some of the important code is already
> independent from the Eclipse API (by using our own IForm interface with
> some "glue" code that is aware of both IForm and Eclipse to show a form
> inside an editor, preference page, dialog, etc.).
> However there is a lot of code that does depend on Eclipse API and there
> are even some hacks that use internal API. At least we use:
> default behavior such as prompting to save (all) on close
> commands/PropertyTester/toolbars (with custom contribution)/menus
> preference pages (We like the tree, filter, secure storage)
> Eclipse help system for user documentation, including context-sensitive
> custom code on top of org.eclipse.ui to make our event, customer and
> product editors only show up in a corresponding perspective
> running code on workbench startup
> Eclipse Job system (less important: progress view)
> (less important: About dialog)
|Re: to migrate or not to migrate? [message #1243776 is a reply to message #1142373]
||Tue, 11 February 2014 07:28
| SlowStrider Mising name
Registered: July 2009
I finally started upgrading my RCP application to the latest Eclipse version which is Kepler (4.3.1).|
Getting the application to compile and run was not very hard, see (1).
However I hit many smaller compatibility issues see (2). Most of them can be worked around. But one of which is a showstopping issue for us which I don't know how to fix so I will use 3.x for the time being. People who don't use any "dirty tricks" can probably safely migrate to 4.x.
We assign a perspective to different types of editors and only show the editors belonging the active perspective and hide the others.
But IWorkbenchPage.hideEditor is not migrated to 4.x.
Uses perspectivePreDeactivate to make it look smooth, this isn't working either.
I am using a custom target platform as advised. Besides the org.eclipse.rcp feature I had to manually add the following features from update site http://download.eclipse.org/releases/kepler/:
EMF - Eclipse Modeling Framework Core Runtime
Eclipse Kepler comes with: 2.9.1.v20130827-0309 so used this version.
Had to add required plugins to launcher, and manually add these plugins for the console to work:
org.apache.felix.gogo.command , org.apache.felix.gogo.runtime , org.apache.felix.gogo.shell
My product is based on a feature, so had to recreate the feature given this launch configuration.
NOT NICE: Impossible to create a fixed UI. Reported this here https://bugs.eclipse.org/bugs/show_bug.cgi?id=427569
(perhaps it can be done with CSS)
Issues I found and solved:
- I don't want the quick access field (solved in Eclipse Luna (4.4)).
- Custom perspective switcher didn't work anymore:
* <dynamic> toolbar contributions don't work anymore (https://bugs.eclipse.org/bugs/show_bug.cgi?id=427475 ), replace by <control>
* <control> contributions being created twice in 4.4M5 (which I tried because I don't wont the quick access field) leading to problems which I can work around
* perspectives have no predictable order anymore (not hard to solve)
- WorkbenchAdvisor's configurer.setSaveAndRestore(false) doesn't work anymore, replaced by command-line argument -clearPersistedState
- Hitting Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=395084 - IWorkbench.showPerspective(id, window) not working after switching to 4.2.1 target which is fixed in a milestone of Luna. Because Luna gives bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=402561 I am using the mentioned workaround.
- Used Swing components and experiencing a bug where parts don't get activated when clicking inside the Swing component https://bugs.eclipse.org/bugs/show_bug.cgi?id=377104
- duplicate menu items, https://bugs.eclipse.org/bugs/show_bug.cgi?id=405262
[Updated on: Tue, 11 February 2014 07:30]
Report message to a moderator
Current Time: Fri Mar 07 06:03:51 EST 2014
Powered by FUDForum
. Page generated in 0.02793 seconds