Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Jubula/JubulaContribGuid"

m (Libraries from Orbit: changed to actual version of git co)
m (From the command line: width of <pre>)
Line 17: Line 17:
  
 
== From the command line ==
 
== From the command line ==
<pre style="width: 40em;">
+
<pre style="width: 48em;">
 
git clone http://git.eclipse.org/gitroot/jubula/org.eclipse.jubula.core.git jubula
 
git clone http://git.eclipse.org/gitroot/jubula/org.eclipse.jubula.core.git jubula
 
</pre>
 
</pre>

Revision as of 14:55, 16 April 2012

Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.
Template:Jubula 

Development IDE Configuration

Jubula has Java 5.0 and Eclipse Platform 3.6 as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

In order to minimize the inadvertent introduction of dependencies to Java 6.0, add both a Java5 and a Java 6 SDK to your workspace. Do this in Window/Preferences -> Java/Installed JREs. Then configure your Execution Environments so that J2SE-1.5 refer to a Java 5 SDK and JavaSE-1.6 refer to a Java 6 installation.

To be completely on the safe side for reducing the risk of breaking Platform 3.6 compatibility, you would have to have a 3.6 IDE ready on which to check your code. In general, the effort for this is probably not justified, unless you are introducing major UI functionality. Just keep the minimum requirements in mind when using Platform API. Eclipse API's are usually marked with a @since tag.

If you are using OS X Snow Leopard, then Java 5 is hard to find. Using the search button in Eclipse will tell you that you have a 1.5.0 version of Java. That is probably a lie. It is just a link to 1.6. Fortunately some nice guys have made a download that you may use. Follow these instructions to download and installl a real Java 5. You do not need to make it default. Downloading, unpacking and fixing the version links is enough.

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 http://git.eclipse.org/gitroot/jubula/org.eclipse.jubula.core.git 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.

Builds

Jubula builds run on build.eclipse.org via Hudson using

Hudson


Build Environment

  • Jubula is built using Maven 3 and Tycho.

Maven Build Sequence

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

[~/src/jubula] $ mvn clean install
[INFO] Scanning for projects...
...

Publishing

The Jubula builds are published via a shell script on build.eclipse.org (you need SSH access to the machine to publish. At the moment, Markus Tiede has publishing privileges).

Signing

To sign the Jubula build, you need to have ssh access to build.eclipse.org and the ability to run /usr/bin/sign

At the moment, Markus Tiede has signing privileges.

The first step is to ensure you're in a place you can sign on build.eclipse.org

cd /home/data/httpd/download-staging.priv/commonBuild

Next you run the signing command (Usage: /usr/bin/sign <file> <mail|nomail> [outputDir]) on a zip of the EGit repo...

sign egit-p2-repo.zip my@email.com /home/data/users/caniszczyk/egit-0.8

After that, you can publish the zip that is generated with the signing information.

Bugs

Links

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

Documentation

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 build.eclipse.org 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.

Tests

Jubula is tested with Jubula. For the time being this tests run on an infrastructure at BREDEX. We plan to move the test to eclipse.org ASAP.

Website

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

  • File > Import > CVS > Projects from CVS
  • Select URL :pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse
  • Use module jubula (from www)
  • Finish

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 eclipse.org


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
selected.

Bug: 12345
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
Signed-off-by: Your Name <your.email@example.org>

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/indigo.target

Back to the top