Eclipse Tooling for JavaFX Project
The most important missing feature is a CSS-Editor who understands the CSS-Extension used by JavaFX 2.0.
Earlier this week, Tom Schindl blogged about the first release of a new project that provides Eclipse Tooling for JavaFX projects, ‘e(fx)clipse.’ JAXenter spoke to Tom Schindl about what niche he’s aiming to fill with e(fx)clipse, and what the future might hold for this new project.
JAXenter: You recently announced a new project: e(fx)clipse. Can you give us an introduction to e(fx)clipse?
Tom Schindl: Before talking a bit about e(fx)clipse I think it is important to understand how e(fx)clipse came into existence. Some people might know that I’m part of the Eclipse 4 development team which is working on the next generation of the Eclipse SDK.
At first I didn’t start with what I later called e(fx)clipse but with the target to teach myself how I can create a DSL using the Xtext 2.0 framework released as part of Eclipse Indigo, and was searching for a medium complex problem with a practical relevance.
At the same time I was working on a proof of concept to make the Eclipse 4 Application Platform using JavaFX as a UI-Library instead of SWT, and so I had to edit JavaFX specific CSS-Files and missed an editor for the vendor extensions. It was a fortunate coincidence because now I had a practical use case for teaching myself a DSL.
I think this bit of history is important when proceeding to talk about e(fx)clipse and what the future holds for it, because there’s currently no commercial, or whatever, hidden agenda.
I naturally welcome if a company thinks that a free and open source Eclipse Tooling for JavaFX 2.0 is needed to make it a success – leaving a big community like the one using Eclipse is probably not ideal! – but I don’t have problems proceeding with it in my spare time because it provides enough technical fun that I’ll keep going.
Anyways, what do I think e(fx)clipse is, and what could it provide:
e(fx)clipse’s main target is to provide tooling to author JavaFX 2.0 applications using the Eclipse IDE, so that developers currently using Eclipse as their primary IDE do not have to switch to e.g. NetBeans to get tooling support when they want to develop applications using this new UI-Toolkit.
Because JavaFX 2.0 applications can be authored with a mixture of Java (or any other JVM-Language) and CSS, and Eclipse provides excellent Java-Tooling out of the box, the most important missing feature is a CSS-Editor who understands the CSS-Extension used by JavaFX 2.0.
Another interesting fact is that I don’t want e(fx)clipse to stop on the tooling front but also provide a runtime framework which supports developers writing medium to big modular JavaFX applications.
The idea is to leverage the runtime platform used by Eclipse 4.1 named “Eclipse 4 Application Platform” to provide such a runtime layer. I’ve already shown in proof of concept implementations that the runtime platform used by Eclipse 4.1 can be used by none SWT-UI applications, so technically it is possible.
JAXenter: Can you give us some potential use cases for an Eclipse Tooling for JavaFX?
Tom: The target audience of the tooling part are naturally all developers who use Eclipse today to develop all kinds of Java-Applications (e.g. WTP, Virgo-Tooling, …) and don’t want to switch to another IDE to author their JavaFX-UIs, which would contradict the idea of an IDE a bit.
The target audience of the runtime framework are developers who want to write modular JavaFX applications using a modern software architecture including OSGi, Dependency Injection and central application model. As far as I know there’s no such framework available as of now, and it simply makes sense to leverage this solid application framework outside the Eclipse SDK project, instead of reinventing and reintegrating those technologies.
JAXenter: What functionality is already available in the 0.0.1 release?
Tom: The only real feature the 0.0.1 release provides is an CSS-Editor which currently provides, besides the default CSS 2.1 attributes, those defined by JavaFX. There is some preliminary support for attribute values but it’s not really sophisticated as of now.
JAXenter: What’s the next step for the e(fx)clipse project?
Tom: From a feature point of view:
0.0.2: Will bring better attribute value proposal support
0.0.3: Will bring validation support, improved outline view
0.0.4: Will focus on e(fx)clipse runtime on top of the “Eclipse 4 Application Platform” (the current biggest problem here is JavaFX itself because it is not designed with strong modularity, as defined by OSGi, in mind)
Out of scope for now is e.g. a WYSIWYG-Editor, which could be built in theory on top of WindowBuilder. It would require a big investment because – at least I – would have to make myself familiar with the WindowBuilder codebase.
Another interesting idea would be to develop a DSL using Xtext to author JavaFX applications, together with the XBase and Xtend2 introduced with Xtext 2.0, this could lead to slick DSL integrated tightly into Eclipse and Java.
From a project organization point of view:
I currently plan to move the Core CSS-Editor codebase to the e4 project because Eclipse 4.x application developers currently face the same problem JavaFX devs do in Eclipse: They’ll have to author CSS-Files with vendor specific extensions but have no tooling.
Because I’m currently the one responsible for the Eclipse 4.x Tooling it makes sense to move the core over to Eclipse.org and proceed with the development of the core there.
The e(fx)clipse code will be developed outside Eclipse.org on my personal github repository.