My recommended project structure for (JavaFX) e4 projects


One of the most important things developing OSGi applications is the bundle structure and because e4 applications are by definition OSGi applications. Before looking in detail on e4 applications let’s look at how you should structure your OSGi projects in my opinion.

The main objectives are decoupeling and minimal dependencies so my suggest is to split up your project in 3 layers:

  • Application layer
  • Framework layer
  • Build and Assembly layer

The application layer

  • (Optional)my.project.${subcomponent}.core.model
    This bundle holds your domain model or DTOs
  • my.project.${subcomponent}.core.services:
    This bundle holds the none UI service interfaces e.g. to communicate with your application server or your persitence layer
  • my.project.${subcomponent}.core.services.mock:
    This bundle holds mock implementations for your service interfaces you use while developing
  • my.project.${subcomponent}.core.services.${name}
    This bundle holds your production implementations for your services
  • my.project.${subcomponent}.core.services.junit
    This bundle holds your JUnit-Compatibility Test-Suite. It’s purpose is to ensure that the different service implementation act like described in your API
  • my.project.${subcomponent}.core.services.${name}.junit
    This bundle holds JUnit-Tests who test specific of this very service implementation
  • (Optional)my.project.ui.views.services
    This bundle holds UI services you want use but are normally provided through the framework. A good example is publishing a selection but because you don’t want to add framework dependencies in your application layer you abstract them away through service definitions
  • my.project.${subcomponent}.ui.views
    This is the bundle where you implement your UI elements. It should only depend on:
    • the widget technology you use (=javafx)
    • javax.inject and javax.annotation so that you can make use of DI
    • my.project.${subcomponent}.core.model
    • my.project.${subcomponent}.core.services
    • my.project.ui.views.services

    IMPORTANT: Do not add dependencies on application frameworks here

Framework integration layer

  • my.project.ui.app
    This bundle holds the main application configuration. In e4 you will have here only your Application.e4xmi where you set up your main application structure, including e.g. the window structure, application commands like Quit, …
  • (Optional)my.project.ui.views.services.${appframework}
    This bundle holds the implementation of ui services for the application framework you want to plug into
  • my.project.${subcomponent}.ui.views.${appframework}
    This bundle holds the integration code of your plain UI-Components into your application framework of choice

Build and Assembly layer

I’m using maven-tycho to build my MANIFEST first OSGi applications but I think other build system (buckminster) would have no problem with the below structure

  • my.project.${subcomponent}.feature
    This feature holds all bundles of this subcomponent
  • my.project.ui.app.jemmy
    This bundle holds the Jemmy-UI-tests for your application
  • my.project.ui.app.product
    In this bundle you find the .product-definition for your final application which is based upon feature
  • my.project.ui.app.releng
    In this bundle you have your main release engeneering project which most likely only holds a pom.xml where you configured the p2-repos to use, …

To give you an example how this would look like I started coding a sample setup as part of the e(fx)clispe repo. Check out the projects starting with “at.bestsolution.efxclipse.demo.twitter”.

project-structure

It is not yet ready to be consumed but we’ll go forward with it in the next days.

About these ads

7 Responses to “My recommended project structure for (JavaFX) e4 projects”

  1. Thanks Tom.

    I’m currently setting up an efxclipse RCP application for my dev team, so the timing of this post is perfect.

    Do you not recommend setting up a target platform? It seems to be considered a best practice: http://www.modumind.com/2012/10/23/rcp-best-practices-set-up-a-target-platform/

    Ron

  2. Hey Tom,
    I’m quite new to splitting up my application into (that many) bundles, but I think a university bachelor project is just the right moment to start thinking about it. However, I’m a bit confused about where to put some things.
    I’m working with EMF and Hibernate and I’m trying to get an e4 + JavaFX + SWT/JFace application running. I also need to read and write files.

    The model and JUnit bundles are self-explaining.
    Is it ok to put the Hibernate stuff in the core.services bundle (non UI, persistence layer)?

    What do you exactly mean by all those “services” – bundles?
    What’s the difference between ui.views and ui.views.${appframework}

    Example:
    I need an OpenFileHandler that – of course – enables the user to choose a file via a file dialog (JavaFX or SWT). I define the Handler in the Application.e4xmi, but where would I put the implementation class?

    Sorry for all those questions, but I really want to do it right this time. This application needs to be modular and extendable, so there really is the need to split it up.

    The mentioned demo.twitter application is – unfortunately – not available at your repo or I can’t find it.

      1. so why are you using both JavaFX and SWT – anyways nice to see e4 used in bachelor projects
      2. service bundles provide you access to data, logic, … – so yes the hibernate stuff should be in your service bundle – i’d envision it looks like this:
        1. Bundle core.services.data has an interface PersonDataAccessor with a methods like getPersons(): List,getPersonByName(String firstname, String lastname): Person
        2. Bundle core.services.data.hibernate has the implementation with the HQL-Queries, …
        3. Bundle core.services.data.mock has mock implementation

        Sidenote: I’d make the services stateless this way they can be moved e.g. to a server one day if you want your application to be 3tier

      3. on all the service bundles: I guess the core.services bundle is clear. Now to the ui.views services let’s use your file dialog sample:
        1. ui.views.service would define an interface FileService with openFile(): File, …
        2. ui.views.service.fx would implement this using the JavaFX-Filedialog
        3. ui.views.service.swt would implement the same using the SWT-Filedialog
      4. I think the openfile handler can be implemented next to your e4xmi because all he’ll do is to delegate to your FileService ;-)
      5. On the twitter sample: Yes I’ve withdrawn it because the twitter rest API drove me nuts! I’ve since then although started on another small application named Bitbucket Manager – The bundles are not following the above names completely but the concepts to split things up are fairly the same. The sources are at https://bitbucket.org/tschindl/bitbucketmgr

Trackbacks/Pingbacks

  1. JavaFX links of the week, December 17 // JavaFX News, Demos and Insight // FX Experience - December 16, 2012

    [...] Eclipse Project creation and deployment (for JavaFX)‘, secondly he posts about his recommended project structure for (JavaFX) e4 projects, and finally he has a post about how EMF-Edit-Support is coming to JavaFX via [...]

  2. e(fx)clipse 0.8.0 released | Tomsondev Blog - January 6, 2013

    [...] good project structure: I’ve blogged about my ideal project structure already some time [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 708 other followers

%d bloggers like this: