I’m pleased to announce that e(fx)clipse 0.1.1 is released just before leaving to JavaOne. Let’s jump directly to list of new features

Distros

I’ve update the 4.2 distro to latest 4.2.1 builds and update all other plugins (Subclipse 1.8.16, GEF 3.8.1, WST 3.4.1, Xtext 2.3.1) in the 3.8 and 4.2 distro to the latest available builds, so the distro will hold the same bundles as the one released with Juno SR1 in the next few days.

Tooling

Our company decided that we are donateing some of our employees time to work on e(fx)clipse opensource stuff. In this release they started working on tooling stuff. So there’s a bunch of cool new features

Build-Tooling

We now have a new fxbuild-File editor which provides support for all features of javafx ant tasks. We have switched the storage from a plain properties file to an XML one which is backed by an EMF-Ecore model.

Old build.fxbuild files should be converter automatically when opened for the first time.

CSS

This area got a lot of love in this release (and will continue in the next ones as well). To provide people meaningful Hover-Tooltips, autocompletion and validation we decided at the begining of the cycle that we need a structural representation of properties and their values so that we can use them. At the moment the only reference is a HTML-File which looks like it is hand-crafted. So we developed our own structural language to collect those informations and use it to

1. Present Documentation
   
2. Provide content proposals
   

The language we use define the possible elements, attributes and values is named and itself looks very similar to what you see in the CSS and FX-CSS specs.

We’ll continue in 0.2.0 implement validation on top this infrastructure and improve the auto-completion which has some rough edges here and there.

FXGraph and FXML

Both of them now validate the fx:id and controller methods you assign and provide you with warnings and errors in case something is not correct.

1. FXGraph Errors/Warnings
   
2. FXML Errors/Warnings
   
The editors not only show the warning and errors but they also provide quick fixes
1. FXGraph
   
2. FXML
   

JavaFX library detection

I’ve decided to remove the different possibilities to locate the javafxrt.jar but instead we’ll make JDK7u7 the minimum version because this one includes javafx. Oracle will in future ship JavaFX 8.0 not as a seperate download and even more important JavaFX 8 will use new Java8 features so you won’t be able to use it with another Java-Version anyways.

You are still free to build applications for JDK6 (by setting the compiler compilance to Java6) on windows where JavaFX is supported but you need to use JDK7 for development.

In conjunction with the NOT shiping of a separate JavaFX a major problem for people is that the JavaDoc is not found in a central place but e(fx)clipse would fall back to JavaFX website which will fail if you have no internet access. The JavaFX team provides an extra download for the JavaFX Javadoc and e(fx)clipse will try to locate it in the following directories:

1. The Projects %JDK_home%/docs/api
2. Your Home-Directory where the javafx-api-%JDK_CONTAINER_NAME%/docs/api – the JDK_CONTAINER_NAME is the one you set for the JDK in your eclipse configuration
   
   Which means for projects who are connected to JDK_7 the path is JDK_7/docs/api.

e4 JavaFX Tooling

To make bootstraping a Jemmy JUnit-Test infrastructure for your OSGi and e4 JavaFX project as simple as possible there’s a new wizard provide to you.


I’ve blogged in more detail about the support in this post.

Research

Inspired by a forum thread I spend a few hours prototyping a JavaFX-Bean definition language to remove the boilerplate code.



I won’t proceed in this area for now but if some community member is interested in proceeding with what I already defined I’m happy to help her/him to get started and pull in changes to the e(fx)clipse git repo.

Runtime

Jemmy Runtime Support

A lot of time has been invested in understanding how to make Jemmy run in an OSGi environment, repackaging and patching it and finally providing the base OSGi-Bootstrap code which launches the application and Jemmy.

I’ve blogged about this in more detail in this post. We also have a basic understanding how we can integrate this into maven-tycho and will most like provide for CI in the next release.

e4 on JavaFX

My biggest working area in this release cycle was on writing a production ready rendering engine for e4 using JavaFX. I’m very satisfied with the result. From my point of view the engine is ready to be used and provides 95% of what you get from the SWT one. Things I’ve not yet implemented are:

• Support for MArea
• Drag and Drop
• Min/Max of support

Because I don’t have big applications like the Eclipse SDK to test the renderers I’m quite sure I missed something here and there but I’m able to fix most problems with in minutes because of the very clean code base.

I’m happy to say that there are the first commerical adopters using e4 on JavaFX to develop applications so I hope others will follow this and make e4 on JavaFX the first technology people will take a look when writing modular desktop applications with JavaFX. If you need to help to start BestSolution.at offers onsite workshops and remote support.

JavaFX and OSGi

I already described above that the tooling requires JDK7u7 now. I decided that the same is the best for the OSGi-Runtime support. Starting with this release e(fx)clipse (Equinox) OSGi-Support will only detect JavaFX inside your JRE. It does NOT support to ship JavaFX with your application. In Java8 JavaFX will be on the bootclasspath anyways so all we need then is an fragment for the system.bundle (this will probably also happen in one of the next Java7 updates).

JavaOne

I’ll be on JavaOne next week and present:

1. e(fx)clipse: Eclipse Tooling and Runtime for JavaFX
2. Eclipse 4.x: A Major Upgrade of Eclipse

If you are at JavaOne or want to discuss Eclipse 4, e(fx)clipse

Share this:

• Twitter
• Facebook
• LinkedIn
• Reddit
• Email
• Print

Like Loading...

Related