Earlier this year I've contributed a patch to ControlsFX to provide OSGi meta data in the Manifest file.
This patch allows ControlsFX to be used more or less out-of-the-box in an OSGi environment such as Drombler FX.
I'm writing "more or less out-of-the-box" since you still need an additional configuration in a Drombler FX application to be able to use ControlsFX.
The latest Drombler FX release provides some documentation in the sample generated by the Drombler FX Maven Archetype about this additional configuration.
You can find this in the generated test-application project in the file src/main/app/conf/config.properties.
You basically have to uncomment some lines there, which looks then like this:
The reason you need this additional configuration is that ControlsFX uses some non-published, internal JavaFX implementation classes and the OSGi environment with the configuration provided by Drombler FX is hiding these classes by default. Adding the necessary packages to org.osgi.framework.system.packages.extra allows ControlsFX to use these classes as well.
Note however that with this configuration these packages are available not only to ControlsFX but to any OSGi bundle in the application. Generally it's strongly discouraged to rely on non-published internal classes as they can change even with any minor release. Backwards compatibility is not maintained for these classes! Using this configuration the OSGi environment cannot protect your own OSGi bundles from using the classes of these packages.
The configuration has been tested with org.controlsfx:controlsfx:8.0.6 and org.controlsfx:controlsfx:8.0.6_20.
Sunday, December 21, 2014
Tuesday, October 21, 2014
Drombler FX: Version 0.5 released
I recently released Drombler FX v0.5. Drombler FX is a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first).
With this release the Docking Framework becomes more lightweight. You don't have to extend any particular Drombler specific class anymore but can extend from any Node such as a layout pane. The DockablePane has been removed from the API.
With this release also icons in Editor Dockings are supported:
The Action Framework has been moved from the OSGi-based RCP Drombler FX to the Drombler Commons library collection, which can be used inside and outside of an OSGi platform.
This allows you to use this framework even if you don't want to use Drombler FX, yet, for some reason.
The Action Framework, keeps the state (enabled/ disabled, selected/ unselected etc.), the information (texts, image etc.) and the logic between menu items and toolbar buttons in sync.
Note that the declarative, annotation based programming model is still only supported by Drombler FX. But there is a sample, which shows how to use this framework from Drombler Commons programmatically.
Please note that because the framework has been moved, some packages have been renamed.
The new Wiki page Logging explains how you can replace the SLF4J binding. The sample application provided by the Drombler FX archetype uses the java.util.logging (JUL) binding by default, because the required jar is very small since java.util.logging is part of the JRE.
The Wiki page shows as a sample how to configure the Log4J 2 binding.
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.5
There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.
Drombler FX uses Apache Felix as its OSGi container by default.
As an application framework it makes sure JavaFX and OSGi will get started properly and it provides the main window.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
You can use the Drombler Forum for questions and discussions.
If you find issues or have enhancement requests, you can file a ticket here: http://issues.drombler.org.
With this release the Docking Framework becomes more lightweight. You don't have to extend any particular Drombler specific class anymore but can extend from any Node such as a layout pane. The DockablePane has been removed from the API.
With this release also icons in Editor Dockings are supported:
The Action Framework has been moved from the OSGi-based RCP Drombler FX to the Drombler Commons library collection, which can be used inside and outside of an OSGi platform.
This allows you to use this framework even if you don't want to use Drombler FX, yet, for some reason.
The Action Framework, keeps the state (enabled/ disabled, selected/ unselected etc.), the information (texts, image etc.) and the logic between menu items and toolbar buttons in sync.
Note that the declarative, annotation based programming model is still only supported by Drombler FX. But there is a sample, which shows how to use this framework from Drombler Commons programmatically.
Please note that because the framework has been moved, some packages have been renamed.
The new Wiki page Logging explains how you can replace the SLF4J binding. The sample application provided by the Drombler FX archetype uses the java.util.logging (JUL) binding by default, because the required jar is very small since java.util.logging is part of the JRE.
The Wiki page shows as a sample how to configure the Log4J 2 binding.
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.5
There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.
Drombler FX uses Apache Felix as its OSGi container by default.
As an application framework it makes sure JavaFX and OSGi will get started properly and it provides the main window.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
| Name | Modules (incl. Maven Coordinates) |
Javadoc | Description |
|---|---|---|---|
| Drombler FX | Modules | Javadoc | Drombler FX is a modular Rich Client Platform for JavaFX based on:
|
| Drombler ACP | Modules | Javadoc | Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
|
| Drombler Commons | Modules | Javadoc | Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment. |
You can use the Drombler Forum for questions and discussions.
If you find issues or have enhancement requests, you can file a ticket here: http://issues.drombler.org.
Wednesday, May 21, 2014
Drombler FX: JavaFX 8 support
I recently released Drombler FX v0.4. Drombler FX is a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first).
With this release Drombler FX as well as Drombler ACP and Drombler Commons support and require JavaFX 8/ Java SE 8.
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.4
There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.
Drombler FX uses Apache Felix as its OSGi container by default.
As an application framework it makes sure JavaFX and OSGi will get started properly and it provides the main window.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
You can use the Drombler Forum for questions and discussions.
If you find issues or have enhancement requests, you can file a ticket here: http://issues.drombler.org.
With this release Drombler FX as well as Drombler ACP and Drombler Commons support and require JavaFX 8/ Java SE 8.
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.4
There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps.
Drombler FX uses Apache Felix as its OSGi container by default.
As an application framework it makes sure JavaFX and OSGi will get started properly and it provides the main window.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
| Name | Modules | Javadoc | Description |
|---|---|---|---|
| Drombler FX | Modules | Javadoc | Drombler FX is a modular Rich Client Platform for JavaFX based on:
|
| Drombler ACP | Modules | Javadoc | Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
|
| Drombler Commons | Modules | Javadoc | Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment. |
You can use the Drombler Forum for questions and discussions.
If you find issues or have enhancement requests, you can file a ticket here: http://issues.drombler.org.
Sunday, May 11, 2014
Drombler FX: Version 0.3 released
I recently released Drombler FX v0.3. Drombler FX is a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first).
With this release the Docking Framework and the Context Framework have been moved from the OSGi-based RCP Drombler FX to the Drombler Commons library collection, which can be used inside and outside of an OSGi platform.
This allows you to use these frameworks even if you don't want to use Drombler FX, yet, for some reason.
Note that the declarative, annotation based programming model is still only supported by Drombler FX. But using the libraries from Drombler Commons you can use the Docking Framework programmatically like this:
Add a DockingPane to the scene and initialize the ContextManager and the DockingManager.
The DockingPane splits up its content area into any number of Docking Areas. The Docking Areas can be resized using the dividers. Each Docking Area can hold any number of Dockable Panes, which are layed out as Tabs.
The ContextManager and the DockingManager manage the Acitve Context and the Application Context depending on the currently open and active Dockable Panes.
Register a Docking Area:
Initialize the DockablePreferencesManager and register the default DockablePreferences for each Dockable Pane type (here: LeftTestPane which should be docked into the Docking Area with ID "left"):
Add a DockablePane (here: LeftTestPane) to the DockingPane:
You can find a complete sample here.
Note that the Docking Framework is still in its early stages and advanced features such as drag'n'drop Dockable Panes don't work yet. Currently it supports:
Here you can find a list of currently known issues and enhancement requests.
Especially have a look at the API issues. Although I took the opportunity and invested a lot of effort to clean up the API in the process of moving the framework from Dromber FX, where the programmatic API was in a hidden package, to Drombler Commons, where a part of the programmatic API has now been published, I'm still not 100% satisfied with the current state. Other opinions are highly welcome!
Please feel free to vote, comment and/ or file new issues.
For more information on the Context Framework have a look at the wiki.
And you can find a complete sample here.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.3
Note that since JavaFX 8 isn't 100% backwards compatible with JavaFX 2.x, this release still only works with Java SE 7/ JavaFX 2.x.
I'm already working on upgrading Drombler FX and Drombler Commons to Java SE 8/ JavaFX 8, however, and it will likely make it into the next release. Stay tuned!
With this release the Docking Framework and the Context Framework have been moved from the OSGi-based RCP Drombler FX to the Drombler Commons library collection, which can be used inside and outside of an OSGi platform.
This allows you to use these frameworks even if you don't want to use Drombler FX, yet, for some reason.
Note that the declarative, annotation based programming model is still only supported by Drombler FX. But using the libraries from Drombler Commons you can use the Docking Framework programmatically like this:
Add a DockingPane to the scene and initialize the ContextManager and the DockingManager.
The DockingPane splits up its content area into any number of Docking Areas. The Docking Areas can be resized using the dividers. Each Docking Area can hold any number of Dockable Panes, which are layed out as Tabs.
The ContextManager and the DockingManager manage the Acitve Context and the Application Context depending on the currently open and active Dockable Panes.
Register a Docking Area:
Initialize the DockablePreferencesManager and register the default DockablePreferences for each Dockable Pane type (here: LeftTestPane which should be docked into the Docking Area with ID "left"):
Add a DockablePane (here: LeftTestPane) to the DockingPane:
You can find a complete sample here.
Note that the Docking Framework is still in its early stages and advanced features such as drag'n'drop Dockable Panes don't work yet. Currently it supports:
- Register Docking Areas and visualize them by adding TabPanes to a custom multi-SplitPane.
- Add Dockable Panes to Docking Areas using a logical Docking Area ID.
- Calculate the minimal required SplitPanes depending on the sparse definition of Docking Areas and the currently open Dockable Panes.
Here you can find a list of currently known issues and enhancement requests.
Especially have a look at the API issues. Although I took the opportunity and invested a lot of effort to clean up the API in the process of moving the framework from Dromber FX, where the programmatic API was in a hidden package, to Drombler Commons, where a part of the programmatic API has now been published, I'm still not 100% satisfied with the current state. Other opinions are highly welcome!
Please feel free to vote, comment and/ or file new issues.
For more information on the Context Framework have a look at the wiki.
And you can find a complete sample here.
The following table provides you an overview of the different Drombler components, links to the modules, which are available from Maven Central, and links to the Javadocs.
| Name | Modules | Javadoc | Description |
|---|---|---|---|
| Drombler FX | Modules | Javadoc | Drombler FX is a modular Rich Client Platform for JavaFX based on:
|
| Drombler ACP | Modules | Javadoc | Drombler Abstract Client Platform (ACP) is an abstract, GUI-toolkit agnostic, modular Rich Client Platform based on:
|
| Drombler Commons | Modules | Javadoc | Drombler Commons is a collection of reusable libraries and frameworks. They ship with OSGi meta data but don't require an OSGi environment. |
You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.3
Note that since JavaFX 8 isn't 100% backwards compatible with JavaFX 2.x, this release still only works with Java SE 7/ JavaFX 2.x.
I'm already working on upgrading Drombler FX and Drombler Commons to Java SE 8/ JavaFX 8, however, and it will likely make it into the next release. Stay tuned!
Friday, April 25, 2014
3rd-Party Contribution: ez-vcard + OSGi Support
Recently I wanted to use ez-vcard
in one of my projects. The project is OSGi-based but unfortunately ez-vcard didn't provide the OSGi meta data in its Manifest file. So what to do?
I decided to go and try to fix ez-vcard itself rather than finding some workaround.
It didn't take too much time to get the sources, add the OSGi meta data generation, fix some other issue which popped up and create a patch. And it didn't take a long time either for the maintainer to accept my patch (with small changes from the maintainer).
Result:
This is one of the real strength of Open Source software: I could quickly fix an issue myself the clean way without having to wait for the maintainer to fix it eventually sometime in the future.
I can only encourage developers not to shy away from getting the sources of 3rd-party Open Source libraries and to fix the issues they have the clean way rather than to search for some workarounds.
I decided to go and try to fix ez-vcard itself rather than finding some workaround.
It didn't take too much time to get the sources, add the OSGi meta data generation, fix some other issue which popped up and create a patch. And it didn't take a long time either for the maintainer to accept my patch (with small changes from the maintainer).
Result:
- I have solved the issue the clean way - the library ships now with the OSGi meta data in the Manifest file.
- The patch is now part of the project and is likely to be maintained along with the project. I won't have to apply the patch with every new version of the library.
- I didn't have to create some workaround, which I would have to maintain myself.
- Last but not least: The issue is now solved not only for me but for anyone else who wants to use the library in an OSGi environment as well.
This is one of the real strength of Open Source software: I could quickly fix an issue myself the clean way without having to wait for the maintainer to fix it eventually sometime in the future.
I can only encourage developers not to shy away from getting the sources of 3rd-party Open Source libraries and to fix the issues they have the clean way rather than to search for some workarounds.
Subscribe to:
Posts (Atom)
Posts
