Eclipse 4 (e4): How, when and why to migrate

Since e4 technology and concepts are in every Juno release and will be downloaded millions of times, many projects are currently evaluating why, when and how to migrate to the Eclipse 4 (e4) Application platform. The why and the when answers are classical, “It depends…”  In fact, the answers depend on many criteria such as the existing components, third-party frameworks used and many more. Additionally, there are different options for the migration, which I have summarized here: </blogs/2012/06/18/migrating-from-eclipse-3-x-to-eclipse-4-e4/>. I’ve also submitted a session to EclipseCon North America to discuss the migration issue in more detail.

https://www.eclipsecon.org/2013/sessions/eclipse-4-why-when-and-how-migrate

However, there is one pattern, which IMHO every project should consider applying - even if no migration to e4 is planned. I think it adds more flexibility and makes components easier to re-use and test. The basic idea is to separate workbench specific parts from parts that can be POJOs – eg. custom implementations and components implementing interfaces such as IViewPart. This is a very fundamental pattern in e4, but can actually be used in 3.x, too. Many projects have been applying this for years. Using the 3.x bridge provided by the e4 tools (developed by Tom Schindl), custom POJO implementations can even use dependency injection. However, even without this bridge, you’ll see that the separation still makes sense.

I’ve received many requests to document this pattern in more in detail so I’ve created a new tutorial as an appendix to our Eclipse 4 tutorial.:

/blogs/tutorials/eclipse-4-e4-tutorial-soft-migration-from-3-x-to-eclipse-4-e4/