Difference between revisions of "Jubula/JubulaContribGuid"
m (→Libraries from Orbit: changed to actual version of git co)
|Line 166:||Line 166:|
= Libraries from Orbit =
= Libraries from Orbit =
Jubula uses some bundles from Orbit. Please use the target platform defined in org.eclipse.jubula.project.configuration/target/definitions/
Jubula uses some bundles from Orbit. Please use the target platform defined in org.eclipse.jubula.project.configuration/target/definitions/.target
Revision as of 13:27, 16 April 2012
- 1 Development IDE Configuration
- 2 Obtaining Sources
- 3 Builds
- 4 Bugs
- 5 Documentation
- 6 Tests
- 7 Website
- 8 Contributing Patches
- 9 Libraries from Orbit
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.
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.
- File > Import > Git > Projects from Git
- Enter URI:
- Import existing projects into the workspace from the newly created working directory
To compile properly you will also need libraries from Orbit.
Jubula builds run on build.eclipse.org via Hudson using
- Jubula is built using Maven 3 and Tycho.
Maven Build Sequence
- To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html and for Tycho additionally pass proxy settings via system properties (https://issues.sonatype.org/browse/TYCHO-279): mvn -DproxyHost=myproxy -DproxyPort=1080 ...
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... ...
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).
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
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 email@example.com /home/data/users/caniszczyk/egit-0.8
After that, you can publish the zip that is generated with the signing information.
|Open Bugs and Enhancements||Open|
|Assigned Bugs and Enhancements||Assigned|
|All Bugs and Enhancements||All|
|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 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.
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.
The Jubula website is located in a CVS repository on the Eclipse Foundation's servers.
- File > Import > CVS > Projects from CVS
- Select URL :pserver:firstname.lastname@example.org/cvsroot/org.eclipse
- Use module jubula (from www)
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 <email@example.com>
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