Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: for the plan.

Jump to: navigation, search


< Jubula(Redirected from Jubula/JubulaContribGuid)


Development IDE Configuration

The Jubula ITE has Java 7 and Eclipse Platform 4.2, the RC code Java 1.4 as minimum requirements, so dependencies to newer Java and platform versions must be - especially for the RC part - avoided.

Obtaining Sources

Jubula is hosted in Git. Browse the repositories in gitweb.

There are several ways to obtain a copy of each repository:

From the command line

git clone jubula

From an installed EGit plugin

First, verify that the default repository folder as set on the main Git preference page is to your liking.

To compile properly you will also need libraries from Orbit.

Workspace setup

We strongly recommend to take our common setup recommendations into account as it'll make it much more easier for us e.g. when providing and reviewing contributions

  • enable Checkstyle "Jubula" within your workspace using a project relative configuration pointing to org.eclipse.jubula.core/org.eclipse.jubula.project.configuration/checkstyle.xml
  • setup your all of your auto-formatter to *not use* tab character for indentation - instead use 4 spaces
  • set org.eclipse.jubula.core/org.eclipse.jubula.project.configuration/target/definitions/ for normal development task as a target definition within the IDE

Via Oomph

Setting up Oomph

Oomph can be extracted to a local folder after downloading it from Eclipse Installer (by Oomph).
You can learn more about the Oomph project at
FAQ is available at Eclipse_Oomph_FAQ

Using Oomph

* Start the Eclipse Installer (by Oomph)
* Select the "Advanced Mode"
* Select Eclipse Product as Eclipse IDE for Eclipse Committers; Product version can be selected as required.
* Double-click the Jubula Project on the second wizard page
* Set the variables as preferred 
* Confirm the installation and wait for Oomph to setup your initial IDE
* After IDE startup wait for the post workspace hooks to be performed (as e.g. clone the git repository, setting preferences and apply target platform configurations)


Jubula builds run on via Hudson using


Build Environment

  • Jubula is built using Maven 3 and Tycho.
  • It's recommended to use Java 8 for compilation to be able to assemble all (especially the JavaFX RC parts) components of Jubula.
  • We're currently expecting a couple native commands being available on the PATH such as
* mvn
* git
* xsltproc
* xmllint
  • due to that it's currently hard to build Jubula within a windows environment

Maven Build Sequence

 * Debian/Ubuntu: ant maven
 * ArchLinux: apache-ant maven

Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):

[~/git/org.eclipse.jubula.core] $ ant
Buildfile: ~/git/org.eclipse.jubula.core/build.xml

Total time: 4 minutes 1 second

Running the command above generates a p2 repository under, which you can use to install it into your Eclipse.


The Jubula builds are published on (you need SSH access to the machine to publish. At the moment, Markus Tiede has publishing privileges).



Trends Jubula
Open Bugs and Enhancements Open
Assigned Bugs and Enhancements Assigned
All Bugs and Enhancements All
Lists Jubula
Open Bugs Open
Open Enhancements Open
Assigned Bugs and Enhancements Assigned


The Jubula project uses LaTeX for it's documentation base. The Online Help is currently build off site and committed to the git repository on demand.

If anyone knows a way to port lots of LaTeX documentations to a system which runs at and support Eclipse Online Help and PDF as output please step forward.

The aim is to generate new documentation every month or so (or just on demand). If you're making big changes or want the documentation refreshed, please let us know on the jubula-dev mailing list.


Jubula is tested with Jubula. For the time being these tests run on an infrastructure at BREDEX.


The Jubula website is located in a git repository on the Eclipse Foundation's servers. Browse the repository in

There are several ways to obtain a copy of each repository:

From the command line

git clone

From an installed EGit plugin

First, verify that the default repository folder as set on the main Git preference page is to your liking.

Contributing Patches

Please create a Bugzilla entry with a patch attached. We are planning to move to gerrit for contributuions as soon as it is generally available at

Granularity of Changes

  • Make small commits, as small as reasonable. This makes them easy to review.
  • Each commit should have a commit message that explains very clearly what the commit sets out to achieve (unless this is abundantly clear from the code itself, which is basically only the case for trivial patches). Also, when you fix a bug then report which bug you fix. When there are deeper reasons for doing things the way the commit does, then explain these as well. This all is for the reviewers and yourself: the context of the commit is completely clear.
  • Do not mix concerns in commits: have a commit do a single thing. This makes them reviewable 'in isolation'. The purpose of the commit is clear and can be understood easily by the reviewers and yourself.
  • Do not break the build and tests for any commit: this is very important for bug hunting.
  • Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.
  • A series of commits should work towards a 'feature' in a clear way and only 'enable' the feature in the last commit of the series.
  • In a series of commits first lay the groundwork and then build on that towards the feature.
  • Do not mix concerns in branches: when you encounter a bug while working on something then create a new branch to fix the bug. If your work depends on the bug being fixed then rebase your work on that new branch.

Commit message guidelines

  • The commit message header should fit on one line and should start with an uppercase letter
  • The commit message have newline characters after every 60-70 characters.
  • A "Signed-off-by" should be added to the end of the commit message (see example below).
  • The first sentence should be a clear and concise description about the change.
  • Enter a newline before providing a more detailed description about the change.
Fix the commit dialog to respect the workbench's selection

Originally, the commit dialog would automatically check off all
files in the dialog. This behaviour contradicts a user's expectation
because their selection in the workbench is completely ignored. The
code has been corrected to only preselect what the user has actually

Bug: 12345
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
Signed-off-by: Your Name <>

Test before submitting

  • Contact the Jubula team to have the tests run on your behalf.
  • Pay attention to the Java and Eclipse SDK baselines. Jubula requires only Java5 and Eclipse 3.6. You cannot use API's that are newer. We often see breakages because Java 6 API's are used.

Libraries from Orbit

Jubula uses some bundles from Orbit. Please use the target platform defined in org.eclipse.jubula.project.configuration/target/definitions/

Back to the top