Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » to migrate or not to migrate?
to migrate or not to migrate? [message #1142373] Thu, 17 October 2013 15:28 Go to next message
SlowStrider Mising name is currently offline SlowStrider Mising nameFriend
Messages: 115
Registered: July 2009
Senior Member
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 #1142374 is a reply to message #1142373] Thu, 17 October 2013 15:28 Go to previous messageGo to next message
SlowStrider Mising name is currently offline SlowStrider Mising nameFriend
Messages: 115
Registered: July 2009
Senior Member
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 help
  • 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 #1142677 is a reply to message #1142374] Thu, 17 October 2013 19:51 Go to previous messageGo to next message
Christophe Bouhier is currently offline Christophe BouhierFriend
Messages: 937
Registered: July 2009
Senior Member
Hi,

I just went a similar "migration" with Eclipse 3.7 RCP with features like:

- xtext
- console, outline, property, help, progress, ide, preferences, memmento
etc..
- a lot of ui.forms
- emf/cdo
- 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
launch config.

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
ibm.icu package).
- 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
mode (yet).

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
> help
> 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 #1143450 is a reply to message #1142677] Fri, 18 October 2013 07:34 Go to previous messageGo to next message
SlowStrider Mising name is currently offline SlowStrider Mising nameFriend
Messages: 115
Registered: July 2009
Senior Member
Thank you so much for your answer! (I didn't even mention UI forms and SharedHeaderFormEditor that we use.)

Good to know that using the compatibility layer isn't too much trouble.
Obviously I am not the only one with the same situation, especially because the whole Eclipse IDE is built on top of the old 3.x concepts. Your answer confirms what I already thought after reading about the lack of many features in pure E4.

So I think the best way is to just do about the same the Eclipse IDE does. So upgrade to the latest version using the compatibility layer. And keep an eye on when features such as preference pages and help system are ported to E4. When the time comes that the Eclipse IDE is ported to pure E4, other existing applications should be easier to port as well!
Re: to migrate or not to migrate? [message #1194964 is a reply to message #1142373] Mon, 18 November 2013 19:47 Go to previous messageGo to next message
Jonas Helming is currently offline Jonas HelmingFriend
Messages: 481
Registered: July 2009
Senior Member
I would go for 3.8 or 4.3. 4.3. allows you to migarte the application
step by step...

Am 17.10.2013 17:28, schrieb SlowStrider Mising name:
> 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 #1243776 is a reply to message #1142373] Tue, 11 February 2014 12:28 Go to previous message
SlowStrider Mising name is currently offline SlowStrider Mising nameFriend
Messages: 115
Registered: July 2009
Senior Member
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.


(1)
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
EMF common

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.

(2)
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 12:30]

Report message to a moderator

Previous Topic:OSGI error on CentOS
Next Topic:to save state of application in e4 using save state in application work bench advisor
Goto Forum:
  


Current Time: Thu Nov 27 03:21:54 GMT 2014

Powered by FUDForum. Page generated in 0.01737 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software