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}
    This bundle holds the none UI service interfaces e.g. to communicate with your application server or your persitence layer
  • my.project.${subcomponent}
    This bundle holds mock implementations for your service interfaces you use while developing
  • my.project.${subcomponent}${name}
    This bundle holds your production implementations for your services
  • my.project.${subcomponent}
    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}${name}.junit
    This bundle holds JUnit-Tests who test specific of this very service implementation
  • (Optional)
    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}

    IMPORTANT: Do not add dependencies on application frameworks here

Framework integration layer

    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)${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
    This bundle holds the Jemmy-UI-tests for your application
    In this bundle you find the .product-definition for your final application which is based upon feature
    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”.


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

This entry was posted in e(fx)clipse. Bookmark the permalink.

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

  1. Ron says:

    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:


  2. Pingback: JavaFX links of the week, December 17 // JavaFX News, Demos and Insight // FX Experience

  3. Pingback: e(fx)clipse 0.8.0 released | Tomsondev Blog

  4. 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 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}

    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.

    • Tom Schindl says:
      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 has an interface PersonDataAccessor with a methods like getPersons(): List,getPersonByName(String firstname, String lastname): Person
        2. Bundle has the implementation with the HQL-Queries, …
        3. Bundle 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 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

Leave a Reply

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

You are commenting using your 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.