Reviews run for a minimum of one week. The outcome of the review is decided on this date. This is the last day to make comments or ask questions about this review.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
All bundles who form the runtime platform (found in the gitrepo in the bundles/runtime folder) provided by e(fx)clipse e.g. to develop JavaFX applications are released as API and can be consumed by developers developing OSGi JavaFX application. All APIs have been JavaDoced and as an extra addon the APIs have been annotated with Eclipse-JDT-Null annotations 2.0 who provide informations if the arguments are expected to be null or not null. Developers who have turned on Eclipse JDT-Nullanalyis will get extra support from their IDE to avoid unexpected runtime errors because of NullPointerExceptionsn.
OSGi Luna Adoption
To integrate JavaFX seemless into a the Equinox-OSGi-Runtime Environment e(fx)clipse makes use of the Equinox-AdapterHook-SPI which was revised in the Luna release of Equinox. e(fx)clipse adopted those changes and now only supports the Equinox-Environment released as part of Luna.
JavaFX applications today are built to a large extend on top of JavaFX8 which is only available as part of Java8 and so all people who use the runtime platform and our tooling have Java8 installed on the system. All bundles have been upgraded to require Java8-SDK as their OSGi-EE. In the our code we adopted Java8 language and API features like lambda-expressions, method-references, Stream-API, ... .
In the 1.0 release cycle we adopted all changes and new features provided by the luna runtime platform. e(fx)clipse has now all features available for e4 on SWT beside one yet not port one - minimize/maximize of parts and stacks. One of the most exciting new features is the DnD support to reorder and repartent stack items to another stack.
The only major area of work that happened in the tooling space was to modify our intelligent CSS-Editor to scan the JDT-Classpath-Container for included libraries and to make use of this information when providing auto-complete and validation informations. The reason behind this feature is that since JavaFX8 developers are able to built custom controls and define their customer CSS-Attributes, by providing a configuration file as part of their library e(fx)clipse will provide developers in the IDE e.g. auto-complete for the custom properties. In the next few months we'll work with well known JavaFX libraries like ControlsFX, JFXExtras and others so that Eclipse IDE users get excellent support for those libraries out of the box.
As outlined above one of the main targets was to get the runtime API in shape for the 1.0 release. This included adding JavaDoc to all public APIs. As an extra services we used JDT-Annotations to encode Null-Informations into the API.
The general documentation on e(fx)clipse is found on our wiki-page. One of the most important pages is our collection of recipes showing best practice useage of some of our APIs and similar page with information on e4 on JavaFX provides informations e.g. about available model tags, ... .
We host some tutorials on getting started with the runtime platform e.g. to develope e4 on JavaFX applications. For developers who want to work with our custom UI-DSL named fxgraph we have a step by step introducation available on our wiki as well.
We started to see code contributions from developers who started to adopt e(fx)clipse are part their work.
Collaboration in and outside Eclipse.org
We worked with upstream Eclipse projects like e.g. JDT to include JavaFX-API doc into the Eclipse-Java-Editor and e.g. the detection JavaFX sources who allow developers to debug into JavaFX source in case somethings going wrong. We are also working with the OpenJFX-Team to e.g. provide additional API on JavaFX controls. We've also been one of the heave JDT8 Beta-Testers and file various bug reports who helped the JDT-Team to get Java8 support in shape for Luna.
SWT on JavaFX
SWT on JavaFX started its life outside Eclipse.org but was contribute by BestSolution.at in the 1.0 timeframe. SWT on JavaFX is a experimental JavaFX who allows RCP developers take their existing SWT UIs and render them through JavaFX. This allows them to migrate their applications from SWT to JavaFX step by step. SWT on JavaFX is not part of this release but the sources are available in our git repo. There are no current plans to invest more time into this area unless we get funded to do so.
We explored writing a Code-Editor which is built on top of Eclipse-Text, while the code-editing framework is not part the release a control who allows people to show StyledText is available as part of the runtime API. We plan to further explore this are in the next releases because it is an excellent test for the runtime platform we are providing.
All e(fx)clipse components are built on top other Eclipse components:
- CSS-Tooling: on top of Xtext
- FXML-Tooling: on top of WST
- FxGraph-Tooling: on top of Xtext
so we automatically inherit the useability built into those tools which matches the experience developers get e.g. by JDT.
Java 6 & 7
All bundles tooling and runtime require Java8. There are only 3 exceptions to this rule
because they are consumed by products like STS who still support Java 7 and so these bundles will stay on Java7
Tooling and Runtime officially don't support Kepler. The runtime integration into OSGi is built on top of the Adapter Hook SPI of Equinox and because Equinox has modified the SPI the new hook implementations won't work on the OSGi-Environment which is part of the Kepler release
Conferences & Democamps
We've shown e(fx)clipse once more at EclipseCon NA and the summer democamp season where we got in touch with people who are already started to adopt e(fx)clipse as a tool or as a runtime platform. One of the highlights was that commercial tools have already been developed on top of e(fx)clipse. We expect more applications who are built on top of e(fx)clipse and plan to built a reference page on our website.
Newsgroup & Forum
The forum at eclipse.org is seeing a steady flow of questions on tooling and runtime parts of e(fx)clipse. We make sure that EVERY question is answered so that people get an excellent free support when useing e(fx)clipse.