Community
Participate
Working Groups
Eclipse 4 (e4) has become unavoidable ! It has been developed for a long time (and even released yearly), but this year, Eclipse 4.2 becomes the primary platform (though each project can also support 4.2), see http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Support_for_Eclipse_3.8_workbench . So I ask : What means going to Eclipse 4 for JWT ? What different steps are they, which ones are unavoidable vs not possible yet vs everything in between ? What & how much effort would each require for JWT ? Here are such possible steps : yearly release, "works in", switches to new, Eclipse 4 specific alternatives of various dependencies (ex. plugin framework & extensions point, XWT...).
First, what does "going 4.2" mean from an administrative point of view? Changes to simultaneous release requirements for Juno are stated here: http://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Changes_for_Juno_Release To sum up: * Project plan * Milestones: they take place earlier than usual for Juno. * Intents to join the simultaneous release should have been stated "by M4 at the latest". I don't know what "M4" is, but I guess it is before M5, which seems to be approximately "January or February". * Initial plans should have been provided by M4 too, by the way. * A section must be added to the project plan, stating what's going to happen regarding 3.8 and 4.2. An example can be found on the WTP plan: http://www.eclipse.org/projects/project-plan.php?projectid=webtools#support38 The project can choose to support only one of the two, or both, and must specify the exact terms (compile against 4.2, test against both, etc.). For JWT to stay in the common repo, it must support 4.2. * Compatibility issues have to be discussed and a section should detail the conclusions * Communication * Capabilities and Project Metrics requirements were dropped * It should be "easy to get released source fom repository". Several hints are provided, but globally it's a bit blurry. Next comes a technical analysis.
Definitely very important! I guess a key question is will there be one JWT or two in the future and if it's only one will it work under both platforms with the same feature set or some limitations.
Some links for further survey. What's new? http://wiki.eclipse.org/Eclipse4/RCP/Architectural_Overview About CSS: http://wiki.eclipse.org/Eclipse4/RCP/CSS Workbench model, application services and compatibility layer: http://wiki.eclipse.org/Eclipse4/RCP Dependency injection: http://wiki.eclipse.org/Eclipse4/RCP/Dependency_Injection
# When will we *have* to port JWT to Eclipse 4? Planned API removals are listed in this document: http://git.eclipse.org/c/platform/eclipse.platform.common.git/plain/bundles/org.eclipse.platform.doc.isv/porting/removals.html#presentation It seems the next big step for Eclipse will be June 2014. Anyway, after a few full-text searches on JWT source tree, it seems none of the API removals will affect JWT. So, regarding the core Eclipse bundles, we're quite safe. # What's interesting in Eclipse 4? A mentioned above, the main advertised benefits of Eclipse 4.2 compared to 3.x are modeled UI, dependency injection and service-based programming model, CSS-based styling. ## Modeled UI Basically, this seems to allow editing the application UI in a declarative, centralized way. One file (the application model) defines the way the interface is organized. The important point here is that this technology is about _application_ UI (from the window level down to the Parts' menus), not about Parts' content. You can build a standalone application using the model, but it's not so useful when developing a plugin. Maybe it could be used to develop the Workflow Perspective? Main sources: * http://wiki.eclipse.org/E4/UI/Modeled_UI#UI_Layer linked from http://wiki.eclipse.org/Eclipse4/RCP * http://www.vogella.com/articles/Eclipse4RCP/article.html#applicationmodel_overview ## CSS-based styling Again, this is about Eclipse applications (based on RCP). Anyway, I don't see how a plugin-specific style could make sense. This would affect very badly the integration to the Eclipse IDE, in my opinion. The only point we should take care of is JWT-specific widgets theming support. Description here: http://wiki.eclipse.org/Eclipse4/RCP/CSS#Extending_CSS_to_handle_new_widgets However, I dont know whether there really is specific widgets in JWT? Maybe the outline view? ## Dependency injection and service-based prog. model Well, *that* is interesting. An extensive overview is available here: http://www.vogella.com/articles/Eclipse4RCP/article.html#dependencyinjectione4 Basically, it's the same as in Spring, for example. It means we can avoid explicitly linking Java objects to one another. Thus, it allows to import fewer packages and create cleaner code (no more ".get().get().get()..."). Eclipse services are already injectable in 4.2. The list is here: http://wiki.eclipse.org/Eclipse4/RCP/EAS/List_of_All_Provided_Services Unfortunately, I couldn't find a comprehensive API documentation (e.g. a javadoc) for Eclipse 4.2, so I don't really know what the new services do. Some are already present in 3.7, though (who said org.eclipse.core.runtime.Platform?). Interestingly enough, these features can be used to inject our own objects and services, by the mean of OSGi services. See here for more information: http://www.vogella.com/articles/Eclipse4RCP/article.html#ownobjects Something that has yet to be examined is the way this injection system integrates with extension points. Would it not be nice if we could inject a factory which could be swapped by JWT extensions? ## Beyond... A key point, in my opinion, is how other plugins will evolve. The future of JWT dependencies might be of greater significance than that of Eclipse itself, both in terms of support and features.
Juno release: Intent has been set, project plan been updated (but still needs to be extended). Will JWT 1.2 be working as a "first-look" release on 4.2 or is it still too unstable on that platform?
Well, I don't know about Eclipse 4.2, but on 4.1 there's a few major bugs. And since we're running on a compatibility layer, there shouldn't be much changes between 4.1 and 4.2... theoretically ;) I have not tested JWT extensively, but for classic use cases (open, edit, export) I already found 2 bugs: * Bug 377647 (fixed, not committed yet) * Bug 377734 (still to be investigated) It all depends on what you mean by "first-look" release. If it's just about showing people that it almost works, even though a few features may still be broken, then that's OK. We can actually use JWT, even though some problems may occur. And we might be able to get things working before Juno, provided that we can participate to the release.
running the tests, a lot of NPEs are thrown: java.lang.NullPointerException at org.eclipse.ui.internal.e4.compatibility.SelectionService.selectionChanged(SelectionService.java:322) at org.eclipse.jwt.we.editors.selection.AbstractSelectionProvider.fireSelectionChanged(AbstractSelectionProvider.java:98) at org.eclipse.jwt.we.editors.selection.SelectionSynchronizer.setSelection(SelectionSynchronizer.java:189) at org.eclipse.jwt.we.editors.selection.SelectionSynchronizer.dispatchSelection(SelectionSynchronizer.java:250) at org.eclipse.jwt.we.editors.selection.SelectionSynchronizer.selectionChanged(SelectionSynchronizer.java:157) at org.eclipse.gef.ui.parts.AbstractEditPartViewer.fireSelectionChanged(AbstractEditPartViewer.java:247) ....
