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.
 
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:
  • 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:
  • 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.

Saturday, December 21, 2013

Drombler Commons: Date and Time Controls use Java SE 8 APIs

I recently released Drombler Commons v0.2. In this release I've ugraded the Date and Time Controls and DataRenderers, which I've released earlier this year, to use the latest version of  the new Date and Time API (JSR-310) provided by the Java SE 8 Early Access Release rather than the outdated version from the initial ThreeTen project.

In this process I've renamed some packages and classes to match the packages and classes of the new Date & Time API, which have been renamed since the last Drombler Commons release.



The aggregated Javadoc of all components can be found here: http://www.drombler.org/DromblerCommons/docs/site/0.2/apidocs/

The source code can be found here.

The components are available from Maven Central (along with the sources and javadoc artifacts). You can use the following dependencies:

For Drombler Commons - FX - Core:

For Drombler Commons - FX - Date and Time (requires Java SE 8):

Thursday, November 7, 2013

Drombler FX: Version 0.2 released

I recently released Drombler FX v0.2. Drombler FX is a modular Rich Client Platform for JavaFX based on OSGi and Maven (POM-first).

For this release, a lot of work has been done in the stabilization of the Docking Framework.

In addition, the icon property gets now respected when registering a Dockable Pane:




Note that the icon property only specifies the name pattern. Drombler FX looks for <icon-base-name>16.<icon-extension> for menu items and tabs (expected to be 16x16 pixels).
In the example above Drombler FX would look for left-test-pane16.png.

Note: Maven expects resources to be in a resources directory. If you're using drombler-fx-parent as your parent POM, it's best to put binary files under the resources-bin directory as this directory has been configured not to be filtered for variables.

With this release Drombler FX now expects the '%' prefix rather than the '#' prefix it used before when identifying resouce strings to be looked up in the Bundle.properties file.
With this change the prefix is now aligned with the prefix used by JavaFX/ FXML.
Since this is an incompatible change, please make sure you replace the prefixes in your code!

You can find the complete list of fixed issues here: http://issues.drombler.org/milestone/0.2/

There's a Getting Started page which explains how to create, build and run a Drombler FX sample application with a few simple steps. 

The artifacts are available from Maven Central.

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.

Note: As this is an Early Access release, all APIs might be subject to change.

Saturday, November 2, 2013

News from the Software Smithy: Version 0.4 released

SoftSmithy news: I recently released a new version of the SoftSmithy Utility Library and the SoftSmithy Development Utility Library.

In addition to some small additions, fixes and clean-ups, some migration work has been done and a new utility library has been added:
  • Project migration: SourceForge.net, where the SoftSmithy project is hosted, migrated to the new Allura based platform. The SCM and some other links changed.
  • SoftSmithy Utility Library - Date & Time has been added. It provides utility classes for the new Date & Time API (Java SE 8). For this I moved some code from the Drombler Commons project to the SoftSmithy project.
    While the other SoftSmity Utility Libraries run with Java SE 7 this utility library requires Java SE 8.
    Note that for easier version management the version of the SoftSmithy Development Utility Library is aligned with the version of the SoftSmithy Utility Library. As the SoftSmithy Development Utility Library has a dependency on the SoftSmithy Utility Library it's recommended to use the same version of both libraries until the APIs are stable!

    You can download the archives (including the jars, documentation, samples etc.) and read more about the changes here:
    SoftSmithy Utility Library v0.4 (online documenation)
    SoftSmithy Development Utility Library v0.4 (online documentation)

    I deployed the artifacts (including the source and javadoc artifacts) to Maven Central. You can use the following dependencies:

    For the SoftSmithy Utility Library - Core:


    For the SoftSmithy Utility Library - AWT:


    For the SoftSmithy Utility Library - Beans:


    For the SoftSmithy Utility Library - Date & Time (requires Java SE 8):


    For the SoftSmithy Utility Library - Persistence:


    For the SoftSmithy Utility Library - Swing:


    For the SoftSmithy Utility Library - Swing - Customizer:


    and

    For the SoftSmithy Development Utility Library (usually with scope = test):

    Friday, April 19, 2013

    Drombler Commons: JavaFX controls for the new Date & Time API (JSR-310)

    I managed to open source and release two more libraries I mainly worked on in spring 2012. They form the first 2 components of this first Early Access version of Drombler Commons: Drombler Commons - FX - Core and Drombler Commons - FX - Date and Time.

    Drombler Commons - FX - Core

    This component contains various JavaFX utility classes.

    Note that this component is still very experimental as I'm trying to figure out what works best with JavaFX.

    Among others it contains:
    The library is available from Maven Central (along with the sources and javadoc artifact):

    The library contains the necessary OSGi meta data and thus is ready for use in a Drombler FX application, but it should also be useable outside an OSGi framework.

    Drombler Commons - FX - Date and Time

    This component is an extension of Drombler Commons - FX - Core and provides controls and DataRenderers for the new Date and Time API (JSR-310), which is planned to be added to the upcoming Java SE 8 release.

    This library provides the following custom controls:
    • MonthOfYearComboBox: a ComboBox to choose an instance of the MonthOfYear enum.
      The text representations of MonthOfYear are locale sensitive (as provided by the Date and Time API).


    • YearMonthSpinner: a skinnable Spinner control for YearMonth.
      The default Skin provides optional Buttons to spin through YearMonth instances and provides a MonthOfYearComboBox and a YearField to let the user change the MonthOfYear and Year directly.
      The text representations of MonthOfYear are locale sensitive (as provided by the Date and Time API).

    • LocalDateFixedYearMonthChooser: a skinnable Control which allows the user to select a LocalDate in a given YearMonth.
      As the complicated name hints, this control is intended as a building block for other controls rather than to be used in applications directly.

    • LocalDateChooser: a skinnable Control which allows the user to select a LocalDate.
      The default Skin combines a LocalDateFixedYearMonthChooser with a YearMonthSpinner.

      The first sample of this control uses the following configuration:
    • selectedDate.max: now.plusWeeks(3) (now=3rd April 2013)
    • selectedDate.min: now.minusMonths(19) (now=3rd April 2013)
    • previousMonths: 1
    • nextMonths: 1
    • locale: en_US (English, United States)

    This sample shows three months at a time: the current year month + 1 previous month + 1 next month.
    Note that the previous year and the previous month scroll buttons are only shown for the first chooser and the next year and the next month scroll buttons are only shown for the last chooser. The other scroll buttons are hidden.

    Since the selectedDate property is a limited property, you can specify an optional min and max date.
    Note that the MonthOfYearComboBox limits the possible values depending on the values set for the min and max date. (Here: the max YearMonth of the center chooser is April 2013, so the possible values for MonthOfYear in 2013 for the previous chooser are: January - March).
    Also note that the year and the month scroll buttons get enabled and disabled depending on the values set for the min and max date. (Here: the year scroll button on the right hand side is disabled.).
    The day buttons are also disabled if the dates are out of range (here: the day buttons are disabled from 25th April 2013 onwards).

    As some months span up to 6 weeks, at least 6 weeks are always shown, where the first week is the week with the first day of the month.

    The week of the year is shown on the left-hand side.

    The dates are colored differently depending on if they are in the shown month or not.

    Here is another sample of the same control with the following configuration:
    • previousWeeks: 2
    • nextWeeks: 1
    • showingWeekOfYear: false
    • showingYearScrollButton: false
    • locale: de_CH (German, Switzerland)



    This sample only shows a single month at a time.

    The previousWeeks and the nextWeeks are added to the standard 6 weeks, so this sample shows 9 weeks.

    Note that in this sample, the week of year column at the left-hand side of the control and the year scroll buttons of the YearMonthSpinner are hidden.

    Also note that not only the days of the week and the months are now shown in German, but the week starts now with Monday, where when using the en_US locale the week starts with Sunday.
    All this locale-sensitive information is provided by the Date and Time API.
    • LocalDatePicker: a skinnable Control which provides a text field and allows to pick the LocalDate from a control.
      The default Skin uses a LocalDateChooser in a pop-up window. You can specify a DataRenderer to format the LocalDate in the text field. Note that the text provided by the default DataRenderer is locale sensitive (as provided by the Date and Time API).




    This components also provides 3 DataRenderers:
    The following packages provide some utility classes:

    The library is available from Maven Central (along with the sources and javadoc artifact):

    The library contains the necessary OSGi meta data and thus is ready for use in a Drombler FX application, but it should also be useable outside an OSGi framework.

    In order to use the Date and Time API jars inside an OSGi framework, you need to register the system packages. In a Drombler FX application you can add the following configuration to your drombler-fx-application module:

    src/main/resources/config.properties


    Since the Date and Time API jars replace some core classes, you need to specify the jars on the bootclasspath. On the command line you can add the following java command line argument:


    where <JAVAX_TIME_0_6_3_HOME> is the parent directory of the Date and Time API jars.

    If this path is stored in an environment variable you can use ${env.JAVAX_TIME_0_6_3_HOME} when you're using the Exec Maven Plugin to run your application.

    Project

    The aggregated Javadoc of both components can be found here: http://www.drombler.org/DromblerCommons/docs/site/0.1/apidocs/

    The source code can be found here.

    Possible Next Steps

    • Visual enhancements: the controls could use some more styling
    • API enhancements: the API needs to be evaluated. Is the existing API fine? Should something be added? It's also not clear to me right now what parts should be configurable via API only, what parts via CSS only and what parts via API and CSS.
    • Migrate to Java SE 8: the latest released JARs and Javadoc of the Date and Time API are quite old. But since spring 2012, when I wrote most of this Drombler Commons code, most if not all code of the Date and Time API has been integrated into Java SE 8. So the Drombler Commons code should be migrated to Java SE 8 as well.
    • Earlier this year a new JavaFX issue has been filed requesting to add a DatePicker control based on the new Date and Time API and people started to work on this issue already.
      I will check the scope of this issue and if some Drombler Commons code can contribute to solve this issue.

    When a core API such as the Date and Time API gets "replaced", you must make sure it integrates well with the existing libraries and frameworks.

    The  Drombler Commons - FX - Date and Time component provides this integrations for JavaFX and shows that, at least with some additional utility methods, the new Date and Time API is fit for that job.

    But I would like to read more about how to integrate the new Date and Time API with other frameworks as well, such as:
    • Controls for Web GUI toolkits such as JSF
    • JAXB: There is a guide how to replace XMLGregorianCalendar with java.util.Calendar or java.util.Date and there are the DatatypeConverter and the DatatypeFactory classes which help to convert to and from XML data types.
      But I haven't found a guide or helper classes to convert to and from the new Date and Time API, yet, though. Especially one which doesn't involve the now legacy API java.util.Calendar and java.util.Date.
    • JDBC: It's great to see that java.sql.Date, java.sql.Time and java.sql.Timestamp already provide some support for the new Date and Time API. But then, is this enough? Or maybe it would be useful to have some direct support in classes such as PreparedStatement and ResultSet as well?
    • JPA: JPA provides support for java.util.Calendar and java.util.Date using the Temporal annotation and the TemporalType enum. The next JPA specification after the Java SE 8 release should add support for as many classes of the Date and Time API as possible, so that these classes can be used in JPA entities as well (the JPA specification is currently part of the Java EE specification and not part of Java SE).