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 "EGit/Contributor Guide"

(To approve a change)
(Development IDE Configuration)
(217 intermediate revisions by 15 users not shown)
Line 1: Line 1:
{{:DocumentationGuidelines/DraftHeader}} {{EGit}}
 
 
 
= Communication =
 
= Communication =
  
Line 26: Line 24:
 
<br/>
 
<br/>
  
= Development IDE Configuration =
+
= Obtaining Sources  =
  
EGit and JGit have Java 5.0 and Eclipse Platform 3.5 as minimum requirements, so dependencies to newer Java and platform versions must be avoided.
+
EGit and JGit are self hosted in Git. You can browse the repositories on the web:
 +
[http://git.eclipse.org/c/egit/ EGit], [http://git.eclipse.org/c/jgit/ JGit]
  
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.
+
The first section below describes how to clone a repository and can be skipped if you have done this before.
  
To be completely on the safe side for reducing the risk of breaking Platform 3.5 compatibility, you would have to have a 3.5 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.
+
The next section lists the repositories and their URLs.
  
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 [http://wiki.oneswarm.org/index.php/OS_X_10.6_Snow_Leopard 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.
+
== Cloning ==
  
== Libraries from Orbit  ==
+
=== On the command line ===
  
=== Install from Orbit P2 Repository ===
+
<pre style="width: 40em;">
 +
git clone <enter URL>
 +
</pre>
  
On the [http://download.eclipse.org/tools/orbit/downloads/ Orbit Downloads] page, click on the newest stable build and copy the update site link from "Orbit Build Repository" (it should end with <tt>/repository</tt>). Add this update site in Eclipse using "Install New Software..." and then find and select the following entries:
+
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.
  
* Java Mocking and Stubbing Framework
+
=== Using EGit (see [http://www.eclipse.org/egit/download/ download page]) ===
* Args4j
+
* Protocol Buffers
+
  
=== Import Team Project Set ===
+
First, verify that the default repository folder as set on the main Git preference page is to your liking.
The simplest way to import the 3rd party libraries needed to compile JGit and Egit:
+
*Download the Team Project Set for [http://wiki.eclipse.org/images/9/9c/GitDependencies.psf git dependencies]
+
*File > Import > Team > Team Project Set
+
*Next
+
*Select the downloaded GitDependencies.psf
+
*logon with user "anonymous", leave password field blank
+
*Finish
+
  
=== Manual Import ===
+
Then, clone the repository and import the projects:
Alternatively to importing the team project set, you may do a manual import of the required libraries:
+
  
''com.google.protobuf''
+
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''
 +
* Selet ''URI''
 +
* Enter the URL (see next section)
 +
* Import existing projects into the workspace from the newly created working directory
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
== Repositories ==
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools'''
+
*Use module '''org.eclipse.orbit/com.google.protobuf'''
+
*Finish
+
*Right click on the project &gt; Team &gt; Switch to another branch
+
*Select tag from following list
+
*Refresh Tags
+
*Versions &gt; v201105131100
+
  
''org.mockito''
+
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed.  
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
=== EGit ===
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools'''
+
*Use module '''org.eclipse.orbit/org.mockito'''
+
*Finish
+
*Right click on the project &gt; Team &gt; Switch to another branch
+
*Select tag from following list
+
*Refresh Tags
+
*Versions &gt; v201102171835
+
  
''org.objenesis''
+
URL: https://git.eclipse.org/r/egit/egit.git
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools'''
+
*Use module '''org.eclipse.orbit/org.objenesis'''
+
*Finish
+
*Right click on the project &gt; Team &gt; Switch to another branch
+
*Select tag from following list
+
*Refresh Tags
+
*Versions &gt; v201006030720
+
  
''org.kohsuke.args4j''
+
=== JGit ===
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
URL: https://git.eclipse.org/r/jgit/jgit.git
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/tools'''
+
*Use module '''org.eclipse.orbit/org.kohsuke.args4j'''
+
*Finish
+
*Right click on the project &gt; Team &gt; Switch to another branch
+
*Select tag from following list
+
*Refresh Tags
+
*Branches &gt; v2_0_12
+
  
''javax.servlet''
+
This is the Java implementation of Git used by EGit, for working with Git repositories.
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
=== EGit GitHub Integration ===
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/tools'''
+
*Use module '''org.eclipse.orbit/javax.servlet'''
+
*Finish
+
*Right click on the project &gt; Team &gt; Switch to another branch
+
*Select tag from following list
+
*Refresh Tags
+
*Branches &gt; v2_5
+
  
<br/>
+
URL: https://git.eclipse.org/r/p/egit/egit-github.git
  
= Obtaining Sources  =
+
EGit also provides tools for integrating with GitHub and Mylyn tasks.
  
EGit and JGit are self hosted in Git. Browse the repositories in [http://egit.eclipse.org/w/ gitweb].
+
For getting the dependencies, open the file <code>org.eclipse.mylyn.github-feature/github.target</code> ([http://git.eclipse.org/c/egit/egit-github.git/plain/org.eclipse.mylyn.github-feature/github.target view on web]) and select ''Set as Target Platfrom''.
<p>There are several ways to obtain a copy of each repository:</p>
+
  
== From the command line ==
+
=== EGit PDE Tools ===
<pre style="width: 40em;">git clone http://egit.eclipse.org/jgit.git jgit
+
git clone http://egit.eclipse.org/egit.git egit
+
git clone http://egit.eclipse.org/egit-pde.git egit-pde
+
git clone http://egit.eclipse.org/egit-github.git egit-github
+
</pre>
+
  
== From an [http://www.eclipse.org/egit/download/ installed] EGit plugin ==
+
URL: https://git.eclipse.org/r/egit/egit-pde.git
First, verify that the default repository folder as set on the main Git preference page is to your liking.
+
  
*File &gt; Import &gt; Git > Projects from Git
+
EGit also provides tools for integrating with [[PDE/Build|PDE Build]] and Eclipse RelEng Tools. If you are an Eclipse developer using PDE Build and/or the Eclipse RelEng tools you might be interesting in the following as well. Otherwise you might just skip this section.
*Clone...
+
*Enter URI: <code>http://egit.eclipse.org/egit.git</code>
+
*Import existing projects into the workspace from the newly created working directory
+
+
  
To compile properly you will also need [[#Libraries from Orbit|libraries from Orbit]].
+
In addition to the [[#Dependencies|dependencies]] required for JGit and EGit you also need Eclipse PDE (>= 3.6.1) as well as <code>org.eclipse.releng.tools</code> in your target platform or checked out from CVS in your workspaces.
  
== EGit PDE Tools ==
+
= Development IDE Configuration =
  
EGit also provides tools for integrating with [[PDE/Build|PDE Build]] and Eclipse RelEng Tools. If you are an Eclipse developer using PDE Build and/or the Eclipse RelEng tools you might be interesting in the following as well. Otherwise you might just skip this section.
+
Download and install the Eclipse package "Eclipse IDE for Eclipse Committers" or "Eclipse for RCP and RAP Developers" from here, if you don't already have it:
  
*File &gt; Import &gt; Git &gt; Projects from Git
+
http://www.eclipse.org/downloads/
*Clone...
+
*Enter URI: <code>git://egit.eclipse.org/egit-pde.git</code>
+
*Import projects
+
  
== EGit GitHub Integration ==
+
== Tools ==
  
EGit also provides tools for integrating with GitHub and Mylyn tasks.
+
'''Note:''' You have to use at least Eclipse 4.3.2 (Kepler SR2), earlier versions had a bug where the following did not work (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=409073 bug 409073]).
  
*File &gt; Import &gt; Git &gt; Projects from Git
+
To install all the necessary tools to work on EGit/JGit, there is a [http://git.eclipse.org/c/egit/egit.git/plain/tools/egit-developer-tools.p2f egit-developer-tools.p2f] file which you can use as follows:
*Enter URI: <code>git://egit.eclipse.org/egit-github.git</code>  
+
 
*Clone...
+
* File > Import > Install > Install Software Items from File
*Import projects
+
* Browse...
*Download dependencies:
+
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''
** automagically: open file <code>org.eclipse.mylyn.github-feature/github.target</code> [http://egit.eclipse.org/w/?p=egit-github.git;a=blob_plain;f=org.eclipse.mylyn.github-feature/github.target;hb=11de1383dc3991dff77b6f0663e06e268ca8689b gitweb] and select 'Set as Target Platfrom'.
+
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it
** manually: In addition to the [[#Libraries from Orbit|libraries from Orbit]] required for JGit and EGit you also need Eclipse PDE (>= 3.6.1) as well as <code>org.eclipse.releng.tools</code> in your target platform or checked out from CVS in your workspaces.
+
* All the items you don't already have should be selected automatically
 +
* Finish the wizard
 +
* Restart
 +
 
 +
== Java Requirements ==
 +
 
 +
EGit and JGit have Java 7.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 3.8.2 (Juno)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.
 +
 
 +
We are using ''PDE/API Tools Environment Descriptions'' (see changes for [https://git.eclipse.org/r/#/c/4785/ JGit] and [https://git.eclipse.org/r/#/c/4365/ EGit]) to facilitate detecting code which isn't working on Java 7. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''PDE/API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].
 +
 
 +
== Dependencies ==
 +
 
 +
After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies. There are a few ways to install these.
 +
 
 +
=== Option 1 (recommended): Use a Target Platform ===
 +
 
 +
[[Image:EGit-Target-Platforms.png‎|right|EGit target platforms in org.eclipse.egit.target]]
 +
 
 +
This is the easiest method to install dependencies:
 +
 
 +
* Open the ''org.eclipse.egit.target'' project
 +
* Choose the ''egit-<version>.target'' file matching the version of your Eclipse platform (e.g. 4.5 for Mars) and open it (this may take a while as it downloads the indexes of the p2 repositories the target platform refers to)
 +
* In the resulting editor, click on the ''Set as Target Platform'' link at the top right (this may also take a while since it downloads the dependencies)
 +
 
 +
After that, the workspace should build cleanly. If not, try Project > Clean... > All. If this also doesn't help open Preferences > Plug-In Development > Target Platform,
 +
select the checked target platform and click "Reload..." this will flush PDE's bundle cache and re-download the artifacts listed in the target platform.
 +
 
 +
There are different target definitions, one for each version of Eclipse that EGit supports. The one you select will be the one that is started if you want to try out a feature or bug fix.
 +
 
 +
You can always switch between them to test on different Eclipse versions. E.g. when you are developing some major UI functionality, you should try it with the oldest supported Eclipse release to make sure it doesn't depend on API that is only available in later versions.
 +
 
 +
=== Option 2: Install from Orbit P2 Repository ===
 +
 
 +
Install the dependencies from the Orbit p2 repository by importing the p2f file described [[#Tools|above]].
 +
 
 +
If you want to try another Orbit p2 repository version on the [http://download.eclipse.org/tools/orbit/downloads/ Orbit Downloads] page, click on the newest recommended build (R-Build) and copy the update site link from "Orbit Build Repository" (it should end with <tt>/repository</tt>). Add this update site in Eclipse using "Install New Software..." and then find and select the following entries:
 +
 
 +
* Java Mocking and Stubbing Framework
 +
* Args4j
 +
* Protocol Buffers
 +
* Apache Jakarta log4j Plug-in
 +
* Apache Commons Compress
 +
* XZ Data Compression
 +
* Hamcrest Library of Matchers
 +
* JavaEWAH
 +
 
 +
== Running ==
 +
 
 +
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:
 +
 
 +
* Right click on the ''org.eclipse.egit.ui'' project
 +
* Debug As &gt; Eclipse Application
 +
 
 +
This should create a new launch configuration and start a new nested Eclipse instance in debug mode. The created launch configuration can be edited, e.g. to change where the workspace of the nested Eclipse should be located.
 +
 
 +
The launch configuration can also be used in normal (non-debug) mode of course.
 +
 
 +
Also see the [http://help.eclipse.org/juno/topic/org.eclipse.pde.doc.user/guide/tools/launchers/eclipse_application_launcher.htm reference on eclipse application launchers].
  
 
<br/>
 
<br/>
Line 163: Line 165:
 
= Builds =
 
= Builds =
  
EGit and JGit builds run on build.eclipse.org via Hudson using
+
The central EGit and JGit builds run on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson instance]
* [http://maven.apache.org/download.html at least Maven 3.0.0]
+
 
 +
Prerequisites for the Maven build are
 +
* [http://maven.apache.org/download.html at least Maven 3.0.0] (but currently not Maven 3.1.0)
 +
* see [http://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration
 +
* if you want to learn how Maven works start reading [http://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]
  
 
Hudson
 
Hudson
* [https://hudson.eclipse.org/hudson/job/jgit JGit@hudson.eclipse.org]
+
* [https://hudson.eclipse.org/egit/master development build jobs]
* [https://hudson.eclipse.org/hudson/job/egit EGit@hudson.eclipse.org]
+
* [https://hudson.eclipse.org/egit/stable maintenance and release build jobs]
  
 
== JGit ==
 
== JGit ==
 
* JGit can be built using Maven 2 or 3.
 
* JGit can be built using Maven 2 or 3.
 +
* use Java 7 to run the JGit Maven build (required since bundle ''org.eclipse.jgit.java7'' needs Java 7)
 
* JGit packaging projects (Eclipse feature and update site) are built using Maven 3 and Tycho.
 
* JGit packaging projects (Eclipse feature and update site) are built using Maven 3 and Tycho.
  
Line 185: Line 192:
  
 
== Maven Build Sequence ==
 
== Maven Build Sequence ==
* Due to a [https://docs.sonatype.org/display/TYCHO/Dependency+on+pom-first+artifacts current limitation of Tycho] it is not possible to mix pom-first and manifest-first builds in the same reactor build hence the pom-first JGit build has to run separately before the build for the manifest-first JGit packaging project.
+
* Due to a [http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts current limitation of Tycho] it is not possible to mix pom-first and manifest-first builds in the same reactor build hence the pom-first JGit build has to run separately before the build for the manifest-first JGit packaging project.
 
* The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.
 
* The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.
* 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): <tt>mvn <b>-DproxyHost=myproxy -DproxyPort=1080</b> ...</tt>
+
* To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html  
  
 
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):
 
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):
Line 209: Line 216:
 
to the jgit p2 repository has to be injected via system property:
 
to the jgit p2 repository has to be injected via system property:
  
<pre style="width: 55em;">[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/
+
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/org.eclipse.jgit.updatesite/target/site
                          org.eclipse.jgit.updatesite/target/site
+
</pre>
+
  
The hudson build on build.eclipse.org uses:
+
The hudson build on build.eclipse.org uses (for SNAPSHOT builds):
<pre style="width: 55em;">[~/src/egit] $ mvn clean install -Djgit-site=https://build.eclipse.org/hudson/job/
+
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/
                          jgit/lastSuccessfulBuild/artifact/org.eclipse.jgit.packaging/
+
                      org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/
                          org.eclipse.jgit.updatesite/target/site/
+
</pre>
+
  
If you wan to build EGit for the specific Galileo platform, consider using the <code>platform-galileo</code> maven profile:
+
If you wan to build EGit for the specific Juno platform, consider using the <code>platform-juno</code> maven profile:
  [~/src/egit] $ mvn -P platform-galileo clean install
+
  [~/src/egit] $ mvn -P platform-juno clean install
 +
 +
For EGit version 3.0, <code>platform-juno</code> (Eclipse 4.2) and <code>platform-kepler</code> (Eclipse 4.3) are available. In addition <code>platform-kepler-staging</code> refers to the Kepler staging repository.
  
3 such platform profiles are currently available: <code>platform-galileo</code> (Eclipse 3.5), <code>platform-helios</code> (Eclipse 3.6), and <code>platform-indigo</code> (Eclipse 3.7).
+
Upon a successful build, a p2 update site should be generated inside ''egit/org.eclipse.egit.repository/target/repository''. If not, make sure the target platform has been downloaded from within Eclipse (Windows>Preferences>Plug-in Development>Target Platform). The default target platform defined in the maven build is currently Eclipse 4.3.
  
 
== FindBugs and PMD ==
 
== FindBugs and PMD ==
  
 
As part of the build, JGit and EGit run FindBugs and PMD to find issues.
 
As part of the build, JGit and EGit run FindBugs and PMD to find issues.
* [https://hudson.eclipse.org/hudson/job/jgit/findbugs JGit FindBugs Results]
+
* [https://hudson.eclipse.org/egit/job/jgit/findbugs JGit FindBugs Results]
* [https://hudson.eclipse.org/hudson/job/jgit/dry JGit DRY (PMD) Results]
+
* [https://hudson.eclipse.org/egit/job/jgit/dry JGit DRY (PMD) Results]
* [https://hudson.eclipse.org/hudson/job/egit/findbugs EGit FindBugs Results]
+
* [https://hudson.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]
* [https://hudson.eclipse.org/hudson/job/egit/dry EGit DRY (PMD) Results]
+
* [https://hudson.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]
  
== Automated Signing and Publishing ==
+
== Checking for JGit API Changes using API Baseline ==
EGit and JGit builds are signed and published using the eclipse-maven-signing-plugin
+
via build.eclipse.org to the folder
+
<pre>
+
/home/data/httpd/download.eclipse.org/egit/updates-nightly
+
</pre>
+
 
+
To enable this procedure the maven profile <code>build-server</code> must be
+
enabled via the option <code>-P build-server</code> in the egit build job
+
running at https://hudson.eclipse.org/hudson/job/egit/
+
 
+
==== Publishing (old method, replaced by automated procedure) ====
+
  
The EGit and JGit builds are published via a shell script on build.eclipse.org (you need SSH access to the machine to publish. At the moment, Chris Aniszczyk (caniszczyk) and Matthias Sohn (msohn) have publishing privileges). There are two scripts that drive the publishing process:
+
The JGit projects have API tooling enabled. In order to use PDE API tools to get assistance with maintaining API changes and additions you need to set an API baseline:
 +
* download the p2 repository for the latest EGit release (which includes the JGit artifacts) to a local folder, e.g. <code>~/egit-releases/updates-4.0</code>, find the p2 repository URLs [http://wiki.eclipse.org/EGit/FAQ#Where_can_I_find_older_releases_of_EGit.3F here] and download the p2 repository of the latest minor release (service releases don't change API) using the corresponding link in the last column of that table
 +
* in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.0) and point it to the local copy of the corresponding EGit p2 repository.
 +
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems
 +
* see the [http://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.
  
 +
== Automated Signing and Publishing ==
 +
EGit and JGit builds running on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson] are automatically signed
 +
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder
 
<pre>
 
<pre>
/home/data/httpd/download.eclipse.org/egit/pubegit.sh
+
master branch:        /home/data/httpd/download.eclipse.org/egit/updates-nightly
/home/data/httpd/download.eclipse.org/egit/pubegit-pde.sh
+
latest stable branch:  /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly
 
</pre>
 
</pre>
  
The script essentially fetches the latest successful build from Hudson and publishes it every three hours via a cron job.
+
* To enable signing the maven profile <code>eclipse-sign</code> must be enabled via the option <code>-P eclipse-sign</code> in the respective build jobs running at https://hudson.eclipse.org/egit/
 +
* To enable publishing to ''download.eclipse.org'' the maven profile <code>publish</code> must be enabled via the option <code>-P publish</code> in the egit build job.
  
 
==== Signing (old method, replaced by automated procedure) ====
 
==== Signing (old method, replaced by automated procedure) ====
Line 272: Line 274:
 
== Contribution to Release Train ==
 
== Contribution to Release Train ==
  
The Indigo release train contribution for JGit and EGit is maintained in the CVS project
+
The release train contribution for JGit and EGit is maintained in the git repository
extssh://dev.eclipse.org/cvsroot/callisto/org.eclipse.indigo.build
+
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre>
 
in the file
 
in the file
egit.b3aggrcon
+
<pre>egit.b3aggrcon</pre>
 +
 
 +
The release train build is coordinated on the [https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev cross-project-issues-dev mailing list]
  
 
<br/>
 
<br/>
  
 
= Documentation =
 
= Documentation =
 +
== JGit ==
 +
The JGit project generates a project report and javadocs using a Maven site. This Maven site is deployed to http://download.eclipse.org/jgit/site/${project.version}.
 +
E.g. http://download.eclipse.org/jgit/site/3.5.0.201409260305-r/
  
 +
Generating the site:
 +
'''$ mvn site:site'''
 +
 +
Staging the site locally under ./target/staging:
 +
'''$ mvn site:stage'''
 +
 +
If you can connect to build.eclipse.org over ssh (ask webmaster if you are a committer and need ssh access) you can deploy a local build of the site:
 +
'''$ mvn site:deploy'''
 +
The site is deployed under http://download.eclipse.org/jgit/site/${project.version}
 +
 +
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:
 +
<server>
 +
      <id>jgit.website</id>
 +
      <username>username</username>
 +
      <privateKey>${user.home}/.ssh/id_rsa</privateKey>
 +
      <filePermissions>664</filePermission>
 +
      <directoryPermissions>775</directoryPermissions>
 +
      <configuration></configuration>
 +
</server>
 +
 +
To deploy the site from EGit HIPP (Hudson) at https://hudson.eclipse.org/egit/ enable the Maven profile '''build-server''' and add the Maven goals '''site:site site:deploy'''.
 +
 +
If you uploaded the site for a new release update the index
 +
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html
 +
to refer to the new release's site.
 +
 +
== EGit ==
 
The EGit project sources its documentation from the wiki and generates Eclipse help content from it (under the covers, we are using [http://wiki.eclipse.org/Mylyn/WikiText Mylyn WikiText] to make this possible). This significantly lowers the barrier for people to contribute documentation to the EGit project. To contribute documentation, simply modify the [http://wiki.eclipse.org/EGit/User_Guide EGit User's Guide]. Have a look at the [[DocumentationGuidelines/StyleGuidelines|Style Guidelines]] and [[Eclipse_Doc_Style_Guide|Eclipse Documentation Style Guide]] to get some guidance on how to write good documentation. More on that can be found [[DocumentationGuidelines|here]].
 
The EGit project sources its documentation from the wiki and generates Eclipse help content from it (under the covers, we are using [http://wiki.eclipse.org/Mylyn/WikiText Mylyn WikiText] to make this possible). This significantly lowers the barrier for people to contribute documentation to the EGit project. To contribute documentation, simply modify the [http://wiki.eclipse.org/EGit/User_Guide EGit User's Guide]. Have a look at the [[DocumentationGuidelines/StyleGuidelines|Style Guidelines]] and [[Eclipse_Doc_Style_Guide|Eclipse Documentation Style Guide]] to get some guidance on how to write good documentation. More on that can be found [[DocumentationGuidelines|here]].
  
The documentation is contained in the '''org.eclipse.egit.doc''' plug-in. The '''build-helper.xml''' drives the generation of the help content. It is integrated into the maven build. The regular maven build of '''org.eclipse.egit.doc'''
+
The documentation is contained in the '''org.eclipse.egit.doc''' plug-in. The '''build-help.xml''' drives the generation of the help content. It is integrated into the maven build. The regular maven build of '''org.eclipse.egit.doc'''
 
  '''$ mvn clean install'''  
 
  '''$ mvn clean install'''  
 
will only package the help content committed to the egit repository. To update the help content by downloading the latest documentation from the wiki run
 
will only package the help content committed to the egit repository. To update the help content by downloading the latest documentation from the wiki run
Line 295: Line 329:
 
= Tests =
 
= Tests =
 
== JGit Unit Tests ==
 
== JGit Unit Tests ==
The JGit unit tests are executed during the maven build for the bundle ''org.eclipse.jgit.test''.
+
The JGit unit tests are executed during the maven build.
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the bundle ''org.eclipse.jgit.test''.
+
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.
  
 
== JGit HTTP Tests ==
 
== JGit HTTP Tests ==
The JGit HTTP tests rely on the Jetty web container. To run these tests from Eclipse install the jetty feature.
+
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.
  
If you are using Helios you can get it from here:
+
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].
  
http://download.eclipse.org/releases/helios
+
Alternatively, install "Jetty 9.2.10.v20150310" from http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.10.v20150310/
 
+
Otherwise install it from here:
+
 
+
http://download.eclipse.org/jetty/7.1.6.v20100715/repository
+
 
+
Feature: Jetty - Core: servlets and webapps
+
  
 
== EGit Core Tests ==
 
== EGit Core Tests ==
 
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.
 
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.
  
To run them from the Eclipse workbench use the launch configuration which is part of the sources of the test bundle ''org.eclipse.egit.core.test''. You will also need to install Mockito, see [[#Libraries_from_Orbit|Libraries from Orbit]].
+
To run them from the Eclipse workbench use the launch configuration which is part of the sources of the test bundle ''org.eclipse.egit.core.test''.
  
 
== EGit UI Tests ==
 
== EGit UI Tests ==
The EGit UI tests are using SWTBot, to run them you need 'SWTBot for Eclipse Testing' feature.
+
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.
  
=== Manual ===
+
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":
Install the SWTBot matching your Eclipse version
+
* Juno and Kepler: http://download.eclipse.org/technology/swtbot/releases/2.1.0/
* Galileo http://download.eclipse.org/technology/swtbot/galileo/dev-build/update-site
+
* Helios and Indigo http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site
+
 
+
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature".
+
  
 
Starting a UI test from Eclipse:
 
Starting a UI test from Eclipse:
Line 334: Line 358:
 
Do not touch the mouse or keyboard when the UI test is running since this may
 
Do not touch the mouse or keyboard when the UI test is running since this may
 
disturb the UI test by e.g. moving the current focus to another window.
 
disturb the UI test by e.g. moving the current focus to another window.
 
=== Automatic ===
 
Using [[RCP_FAQ#What_is_the_recommended_target_platform_setup.3F_Or:_How_can_I_build_and_run_my_RCP_app_against_a_different_version_of_the_Eclipse_base.3F|target platform]] definition file:
 
* http://egit.eclipse.org/r/382 provides core Galileo-based dependencies and SWTBot for Eclipse Testing feature. You still need JGit projects to be opened in the workspace.
 
* http://egit.eclipse.org/r/383 extends the previous one with JGit from the nightly update site. This patch makes it possible to develop EGit plug-ins without checking out JGit projects.
 
 
How to use it:
 
* pull either first or both patches
 
* open Target Platform Preferences page (Window - Preferences - Plug-in development - Target Platform)
 
* activate 'SWTBot-based UI plug-in tests' target platform
 
  
 
=== During Maven Build ===
 
=== During Maven Build ===
Line 349: Line 363:
 
The tests are executed in the integration-test phase of the [http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html default Maven lifecycle].
 
The tests are executed in the integration-test phase of the [http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html default Maven lifecycle].
  
If you want to skip execution of UI tests during the maven build run
+
If you want to skip execution of UI tests (only execute core tests):
  
 
  mvn -P skip-ui-tests clean install
 
  mvn -P skip-ui-tests clean install
 +
 +
If you want to skip all tests:
 +
 +
mvn clean install -Dmaven.test.skip=true
  
 
== Auxilary testing tools ==
 
== Auxilary testing tools ==
Line 357: Line 375:
 
Any code, including testing code, does not always do what you expected it to. The most common failure is probably the failure to actually execute the part of the code you wanted to test. Code coverage tools like [http://www.eclemma.org/ EclEmma] can easily visualize what part of the code is being executed.
 
Any code, including testing code, does not always do what you expected it to. The most common failure is probably the failure to actually execute the part of the code you wanted to test. Code coverage tools like [http://www.eclemma.org/ EclEmma] can easily visualize what part of the code is being executed.
  
== Manual alpha testing ==
+
= Bugs =
In order to manually test your new feature
+
 
* click '''Run > Run Configurations...'''
+
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":
* create a new launch configuration of type "Eclipse Application"
+
* click '''Run'''
+
* for debugging start the same launch configuration from '''Debug > Debug Configurations...'''
+
  
also see the [http://help.eclipse.org/helios/topic/org.eclipse.pde.doc.user/guide/tools/launchers/eclipse_application_launcher.htm reference on eclipse application launchers]
+
[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20bugday%2C%20&keywords_type=anywords&list_id=7364111&resolution=---&query_format=advanced&product=EGit EGit bugs with helpwanted or bugday]
 +
 
 +
[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20bugday%2C%20&keywords_type=anywords&list_id=8951656&product=JGit&query_format=advanced&resolution=--- JGit bugs with helpwanted or bugday]
  
= Bugs =
 
 
== Links ==
 
== Links ==
 
=== Filing Bugs ===
 
=== Filing Bugs ===
[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]
+
==== How to file bugs ====
 +
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]]
 +
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]
 +
*[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham
  
[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]
+
==== File a bug ====
 +
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]
 +
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]
  
 
=== Bug Reports and Links ===
 
=== Bug Reports and Links ===
 
{| cellpadding="3" cellspacing="0" border="1"
 
{| cellpadding="3" cellspacing="0" border="1"
!Trends
+
!Trends (bugs and enhancements)
!EGit
+
!EGit  
 
!JGit
 
!JGit
 
|-
 
|-
|Open Bugs and Enhancements
+
|Open by component (date range editable)
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED Open]
+
|[https://bugs.eclipse.org/bugs/chart.cgi?category=EGit&datefrom=2011-01-01&dateto=&gt=1&label0=EGit%20Core%20Open&label1=EGit%20UI%20Open&labelgt=Grand%20Total&line0=1480&line1=1478&name=1478&subcategory=UI&action=wrap&width=1000&height=500 Open]
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED Open]
+
|[https://bugs.eclipse.org/bugs/chart.cgi?category=JGit&datefrom=2011-01-01&dateto=&label0=JGit%20Open&line0=1592&name=1592&subcategory=JGit&action=wrap&width=1000&height=500 Open]
 +
|-
 +
|Open by status
 +
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]
 +
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]
 
|-
 
|-
|Assigned Bugs and Enhancements
+
|Assigned  
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned]
+
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned]  
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]
 
|-
 
|-
|All Bugs and Enhancements
+
|Open and closed by status
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]
 
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]
Line 395: Line 420:
 
!JGit
 
!JGit
 
|-
 
|-
| Open Bugs
+
| <span style="color:red">Unresolved for passed target milestones</span>
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=VERIFIED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&order=bug_severity Open]
+
| [https://bugs.eclipse.org/bugs/buglist.cgi?f1=OP&list_id=7727637&f0=OP&classification=Technology&f4=CP&query_format=advanced&j1=OR&f3=CP&f2=everconfirmed&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=EGit&target_milestone=0.10.0&target_milestone=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.11&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.12&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.6.0-M1&target_milestone=0.6.0-M2&target_milestone=0.6.0-M3&target_milestone=0.7.0&target_milestone=0.8.0&target_milestone=0.9.0&target_milestone=0.9.0-M1&target_milestone=0.9.0-M2&target_milestone=0.9.0-M3&target_milestone=1.0.0&target_milestone=1.1&target_milestone=1.1-M1&target_milestone=1.1-M2&target_milestone=1.1-M3&target_milestone=1.2&target_milestone=1.2-M1&target_milestone=1.2-M2&target_milestone=1.3&target_milestone=1.3-M1&target_milestone=2.0&target_milestone=2.0-M1&target_milestone=2.0-M2&target_milestone=2.1&target_milestone=2.1-M1&target_milestone=2.2&target_milestone=2.2-M1&target_milestone=2.2-M2&target_milestone=2.3&target_milestone=2.4&target_milestone=3.0&target_milestone=3.0.1&target_milestone=3.0.2&target_milestone=3.1&target_milestone=3.2 Open]
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=VERIFIED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&order=bug_severity Open]
+
| [https://bugs.eclipse.org/bugs/buglist.cgi?f1=OP&list_id=7727591&f0=OP&classification=Technology&f4=CP&query_format=advanced&j1=OR&f3=CP&f2=everconfirmed&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=JGit&target_milestone=0.10.0&target_milestone=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.11&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.12&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.6.0&target_milestone=0.7.0&target_milestone=0.8.0&target_milestone=0.9.0&target_milestone=0.9.0-M1&target_milestone=0.9.0-M2&target_milestone=0.9.0-M3&target_milestone=1.0.0&target_milestone=1.1&target_milestone=1.1-M1&target_milestone=1.1-M2&target_milestone=1.1-M3&target_milestone=1.2&target_milestone=1.2-M1&target_milestone=1.2-M2&target_milestone=1.3&target_milestone=1.3-M1&target_milestone=2.0&target_milestone=2.0-M1&target_milestone=2.0-M2&target_milestone=2.1&target_milestone=2.1-M1&target_milestone=2.2&target_milestone=2.2-M1&target_milestone=2.2-M2&target_milestone=2.3&target_milestone=2.4&target_milestone=3.0&target_milestone=3.0.2&target_milestone=3.1&target_milestone=3.2 Open]
 
|-
 
|-
| Open Enhancements
+
| Open bugs
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=VERIFIED&bug_severity=enhancement&order=bug_severity Open]
+
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&order=bug_severity Open]
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=VERIFIED&bug_severity=enhancement&order=bug_severity Open]
+
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&order=bug_severity Open]
 
|-
 
|-
| Assigned Bugs and Enhancements
+
| Open enhancements
 +
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_severity=enhancement&order=bug_severity Open]
 +
| [https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=NEW&bug_status=REOPENED&bug_status=UNCONFIRMED&bug_status=ASSIGNED&bug_severity=enhancement&order=bug_severity Open]
 +
|-
 +
| Bugs with votes
 +
| [https://bugs.eclipse.org/bugs/buglist.cgi?f1=votes&list_id=2849777&columnlist=votes%2Cproduct%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&o1=greaterthan&resolution=---&v1=1&classification=Technology&query_format=advanced&product=EGit With Votes]
 +
| [https://bugs.eclipse.org/bugs/buglist.cgi?f1=votes&list_id=2849777&columnlist=votes%2Cproduct%2Ccomponent%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cchangeddate&o1=greaterthan&resolution=---&v1=1&classification=Technology&query_format=advanced&product=JGit With Votes]
 +
|-
 +
|Assigned bugs and enhancements
 
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]
 
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]
 
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]
 
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]
Line 410: Line 443:
 
! colspan=2 | EGit and JGit
 
! colspan=2 | EGit and JGit
 
|-
 
|-
| Open EGit and JGit Bugs
+
| Open EGit and JGit bugs
| colspan=2 | [https://bugs.eclipse.org/bugs/report.cgi?y_axis_field=bug_status&cumulate=1&format=bar&x_axis_field=product&query_format=report-graph&short_desc_type=allwordssubstr&product=EGit&product=JGit&longdesc_type=allwordssubstr&bug_file_loc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&keywords_type=allwords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&bug_status=VERIFIED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&emailtype2=substring&bug_id_type=anyexact&chfieldto=Now&action=wrap&field0-0-0=noop&type0-0-0=noop Open]
+
| colspan=2 | [https://bugs.eclipse.org/bugs/report.cgi?y_axis_field=bug_status&cumulate=1&format=bar&x_axis_field=product&query_format=report-graph&short_desc_type=allwordssubstr&product=EGit&product=JGit&longdesc_type=allwordssubstr&bug_file_loc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&keywords_type=allwords&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=REOPENED&bug_status=ASSIGNED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&emailtype2=substring&bug_id_type=anyexact&chfieldto=Now&action=wrap&field0-0-0=noop&type0-0-0=noop Open]
 
|-
 
|-
| Assigned EGit and JGit Bugs
+
| Assigned EGit and JGit bugs
 
| colspan=2 | [https://bugs.eclipse.org/bugs/report.cgi?y_axis_field=bug_status&cumulate=1&format=bar&x_axis_field=product&query_format=report-graph&short_desc_type=allwordssubstr&product=EGit&product=JGit&longdesc_type=allwordssubstr&bug_file_loc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&keywords_type=allwords&bug_status=ASSIGNED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&emailtype2=substring&bug_id_type=anyexact&chfieldto=Now&action=wrap&field0-0-0=noop&type0-0-0=noop Assigned]
 
| colspan=2 | [https://bugs.eclipse.org/bugs/report.cgi?y_axis_field=bug_status&cumulate=1&format=bar&x_axis_field=product&query_format=report-graph&short_desc_type=allwordssubstr&product=EGit&product=JGit&longdesc_type=allwordssubstr&bug_file_loc_type=allwordssubstr&status_whiteboard_type=allwordssubstr&keywords_type=allwords&bug_status=ASSIGNED&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&emailtype2=substring&bug_id_type=anyexact&chfieldto=Now&action=wrap&field0-0-0=noop&type0-0-0=noop Assigned]
 
|-
 
|-
| New Bugs opened
+
| New bugs opened
 
| [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=EGit&product=JGit&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=-1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]
 
| [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=EGit&product=JGit&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=-1d&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]
 
| [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=EGit&product=JGit&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=-1w&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]
 
| [https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=product&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=EGit&product=JGit&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=-1w&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]
Line 430: Line 463:
  
 
<br/>
 
<br/>
 +
 +
To get notified of bugs, go to your e-mail preferences and add <product>.<component>-inbox@eclipse.org to your watch list. For example to get notified of EGit UI bugs, add ''egit.ui-inbox@eclipse.org''.
  
 
==  Keywords ==
 
==  Keywords ==
Line 464: Line 499:
 
= Website =
 
= Website =
  
The EGit and JGit websites are located in a CVS repository on the Eclipse Foundation's servers.
+
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.
  
''egit''  
+
'''egit'''
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
*File &gt; Import &gt; Git &gt; Projects from Git
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse'''  
+
* Select URL  
*Use module '''egit''' (from '''www''')
+
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''
*Finish
+
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''
 +
* in Repositories View on node "origin" click "Gerrit Configuration..." and select branch "master", then changes you push to upstream will end up in Gerrit for review and can be submitted there
  
''jgit''  
+
'''jgit'''
  
*File &gt; Import &gt; CVS &gt; Projects from CVS
+
*File &gt; Import &gt; Git &gt; Projects from Git
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse'''  
+
* Select URL  
*Use module '''jgit''' (from '''www''')
+
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''
*Finish
+
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''
 +
* in Repositories View on node "origin" click "Gerrit Configuration..." and select branch "master", then changes you push to upstream will end up in Gerrit for review and can be submitted there
  
 
<br/>
 
<br/>
Line 484: Line 521:
 
= Contributing Patches  =
 
= Contributing Patches  =
  
Review the following style guides:
+
== Using Gerrit at Eclipse ==
  
*[http://egit.eclipse.org/w/?p=jgit.git;a=blob;f=SUBMITTING_PATCHES;hb=HEAD JGit SUBMITTING_PATCHES]
+
EGit and JGit projects are using [http://code.google.com/p/gerrit/ Gerrit Code Review] for Git based patch submission and review.  
*[http://egit.eclipse.org/w/?p=egit.git;a=blob;f=SUBMITTING_PATCHES;hb=HEAD EGit SUBMITTING_PATCHES]
+
  
Currently the project is using [http://code.google.com/p/gerrit/ Gerrit Code Review] for Git based patch submission and review.
+
Parts of this chapter are also available in the [http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].
  
 +
=== User Account ===
 +
*In order to contribute you need an [https://dev.eclipse.org/site_login/createaccount.php Eclipse user account] on eclipse.org, on creation of a new account you must agree to the Contributor Agreement.
  
== Using Gerrit hosted at egit.eclipse.org with git command line: ==
+
=== Legal Paperwork ===
  
*[http://egit.eclipse.org/register Register a user account]  
+
Before your first contribution can be accepted, you need to electronically sign the [http://www.eclipse.org/legal/CLA.php Eclipse Foundation Contributor License Agreement] (CLA). You only have to do this once, and it covers all Eclipse projects.
*Use ''Register New Email'' to register your email address with our Gerrit Code Review server. This step is required to validate the address is correct.  
+
The new process was discussed in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=381105 bug 381105] and [http://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00933.html introduced on June 27, 2013].
*Add one or more public SSH keys.
+
 
 +
Minimally, all Git commits you contribute must have the following:
 +
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;
 +
* Your credentials (email address) captured in the "Author" field; and
 +
* A "Signed-off-by" entry with matching credentials in the comment.
 +
* The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the [http://www.eclipse.org/legal/CoO.php Certificate of Origin].
 +
 
 +
In addition ensure
 +
* that the contributed code is licensed under the project license (EPL for EGit and EDL for JGit). This is done by putting a [http://www.eclipse.org/legal/copyrightandlicensenotice.php copyright and license header] into every new java file. See other existing project source files for the correct content.
 +
 
 +
With a valid CLA on file, the signed-off commit and the copyright and license header in place, we will be able to accept small patches (<1000 LoC) immediately. For larger patches, we will also have to create a contribution questionnaire for review by the Eclipse IP team, but this usually doesn't require additional actions from you.
 +
 
 +
To verify whether a contribution [https://dev.eclipse.org/mhonarc/lists/eclipse.org-committers/msg00973.html requires a CQ], use one of the following git commands to check:
 +
* If it's committed:  git log --shortstat
 +
* If not committed: git diff --stat
 +
These commands tell you the number of insertions(+), and deletions(-). If the total number of lines inserted (e.g. added) in a contribution is greater than 1000 (yes, this includes comments) then a CQ is required.
 +
 
 +
Find more details about how to contribute in [http://wiki.eclipse.org/Development_Resources/Contributing_via_Git Contributing via Git (for contributors)] and [http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions Handling Git Contributions (for committers)].
 +
 
 +
=== Logon ===
 +
 
 +
====Gerrit Web UI====
 +
Logon to the Gerrit Web UI at <code>https://git.eclipse.org/r/</code> using the email address you registered with your Eclipse (and Bugzilla) account and your Eclipse password.
 +
 
 +
====Git over SSH====
 +
When accessing Gerrit over SSH from git or EGit use the username displayed [https://git.eclipse.org/r/#/settings/ here] and upload your public SSH key to Gerrit [https://git.eclipse.org/r/#/settings/ssh-keys here].
 +
 
 +
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code>
 +
 
 +
====Git over HTTPS====
 +
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]
 +
 
 +
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code>
 +
 
 +
=== SSH Keys ===
 +
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. 
 +
* If you are '''absolutely certain''' you do not have keys already, you must create a public and private pair of SSH keys. It is strongly recommended that you [http://help.github.com/working-with-key-passphrases use a passphrase.]
 +
* '''Generating SSH key pair on command line'''
 +
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre>
 
*Execute SSH once to accept the host key (or copy it from the registration web page)
 
*Execute SSH once to accept the host key (or copy it from the registration web page)
<pre style="width: 60em;">ssh -p 29418 username@egit.eclipse.org
+
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org
 
</pre>  
 
</pre>  
*[http://egit.eclipse.org/r/#settings,new-agreement Confirm you agree] to the Eclipse.org Terms of Service by completing the Individual Contributor agreement.  
+
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]
*Upload your patch from Git to the target project:  
+
 
**JGit
+
=== Doing Code Reviews with Gerrit ===
<pre style="width: 60em;">git push ssh://username@egit.eclipse.org:29418/jgit.git HEAD:refs/for/master
+
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing,
 +
*[https://git.eclipse.org/r/#/settings/projects Register to watch projects] if you want to be notified by email on new or updated changes pushed for review
 +
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs
 +
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.
 +
*The [http://wiki.eclipse.org/EGit/User_Guide#EGit_Tutorial_.28EclipseCon_Europe_Nov_2011.29 EGit tutorial] walks you through the basic steps of working with Gerrit and EGit.
 +
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:
 +
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]
 +
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]
 +
 
 +
=== Using Gerrit with git command line: ===
 +
*Upload your patch from Git to the target project:
 +
 
 +
'''JGit'''
 +
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master
 
</pre>  
 
</pre>  
**EGit
+
'''EGit'''
<pre style="width: 60em;">git push ssh://username@egit.eclipse.org:29418/egit.git HEAD:refs/for/master
+
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master
 
</pre>  
 
</pre>  
*Visit our [http://egit.eclipse.org/r/ Gerrit Code Review instance] to start reviewing
 
  
Or, create a [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit new bug] and attach a Git formatted patch file, as produced by the `git format-patch` tool.
+
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing
  
=== Adding a dedicated remote ===
+
==== Adding a dedicated remote ====
  
 
Since git can have multiple remotes, you can define one to be used to refer to Gerrit to save typing. Inside a previously checked-out repository you can run:  
 
Since git can have multiple remotes, you can define one to be used to refer to Gerrit to save typing. Inside a previously checked-out repository you can run:  
 
<pre>cd path/to/jgit
 
<pre>cd path/to/jgit
git config remote.review.url ssh://username@egit.eclipse.org:29418/jgit.git
+
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git
 
git config remote.review.push HEAD:refs/for/master
 
git config remote.review.push HEAD:refs/for/master
  
 
cd path/to/egit  
 
cd path/to/egit  
git config remote.review.url ssh://username@egit.eclipse.org:29418/egit.git
+
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git
 
git config remote.review.push HEAD:refs/for/master
 
git config remote.review.push HEAD:refs/for/master
 
</pre>  
 
</pre>  
Line 527: Line 615:
 
</pre>
 
</pre>
  
== Using Gerrit hosted at egit.eclipse.org with EGit: ==
+
=== Using Gerrit with EGit: ===
 
+
*[http://egit.eclipse.org/register Register a user account]
+
*Use ''Register New Email'' to register your email address with our Gerrit Code Review server. This step is required to validate the address is correct.
+
*Add one or more public SSH keys to Gerrit.  If you are '''absolutely certain''' you do not have keys already, you must create a public and private pair of keys.  It is strongly recommended that you [http://help.github.com/working-with-key-passphrases use a passphrase.]
+
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre>
+
 
Eclipse will look for your private key in the SSH2 Home location specified in the General&gt;Network Connections&gt;SSH2 Preference Page.  If your <code>id_rsa</code> private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least <code>com.jcraft.jsch 0.1.44</code> to make use of it.
 
Eclipse will look for your private key in the SSH2 Home location specified in the General&gt;Network Connections&gt;SSH2 Preference Page.  If your <code>id_rsa</code> private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least <code>com.jcraft.jsch 0.1.44</code> to make use of it.
*[http://egit.eclipse.org/r/#settings,new-agreement Confirm you agree] to the Eclipse.org Terms of Service by completing the Individual Contributor agreement.  
+
* [[EGit/User_Guide#Cloning_Remote_Repositories | Clone the JGit and EGit repositories]] and select '''Gerrit Configuration...''' in the context menu of the remote "origin" in the Git Repositories view to [http://wiki.eclipse.org/EGit/User_Guide#Gerrit_Configuration configure pushing to the code review queue].
*In the Git Repositories view:
+
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote
**JGit
+
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push.  A unique name should be chosen, ''review'' is suggested.
***From the appropriate Remotes node, create a New Remote and choose to Configure for Push.  A unique name should be chosen, ''review'' is suggested.
+
** Changes committed to your local clone can now be pushed to Gerrit using the ''review'' RemoteYou will be prompted for your private key's passphrase if Eclipse is looking for it in the right place.
***Change the main URI or Add a Push URI of <code>ssh://username@egit.eclipse.org:29418/jgit.git</code>Your Gerrit user name and password must be entered.
+
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:
***In the Ref Mapping section, Add a RefSpec Specification of <code>HEAD:refs/for/master</code>
+
** Change the main URI or Add a Push URI (your Gerrit user name must be used here)
**EGit
+
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code>   
***From the appropriate Remotes node, create a New Remote and choose to Configure for push. A unique name should be chosen, ''review'' is suggested.
+
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code>
***Change the main URI or Add a Push URI of <code>ssh://username@egit.eclipse.org:29418/egit.git</code>  Your Gerrit user name and password must be entered.
+
***In the Ref Mapping section, Add a RefSpec of <code>HEAD:refs/for/master</code>
+
  
*Changes Committed to your local clone will now be able to be Pushed to Gerrit using the ''review'' Remote. You will be prompted for your private key's passphrase if Eclipse is looking for it in the right place.
+
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing
  
*Visit our [http://egit.eclipse.org/r/ Gerrit Code Review instance] to start reviewing
+
=== Using the Mylyn Gerrit Connector ===
 +
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.
 +
 
 +
It contains several useful features:
 +
* Cloning from Gerrit and automatic configuration
 +
** The wizards "Import Projects from Git" and "Clone Git Repository" will offer the possibility to browse the list of repositories on Gerrit servers and to clone selected repositories. After cloning the Gerrit configuration will be done automatically.
 +
* Importing Gerrit changes as Mylyn tasks
 +
* Fetching patch sets directly from the task editor
 +
* Reviewing changes in the task editor
 +
* Submitting changes from the task editor
  
 
== Granularity of Changes ==
 
== Granularity of Changes ==
 +
 
* Make small commits, as small as reasonable. This makes them easy to review.
 
* 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.
 
* 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.
Line 557: Line 648:
 
* 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.
 
* 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.
 
* 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.
+
 
 +
=== Branches ===
 +
 
 +
When working with Gerrit, you can create local branches as you wish. When you are ready to push your changes, only the commits from your branch are pushed and are converted to reviews on Gerrit. The branch name itself is not visible on Gerrit.
 +
 
 +
Do not mix unrelated changes in branches: When you encounter a bug while working on something then create a new branch to fix the bug. Make sure you base it on the state of the remote branch that you want your fix to go to, e.g. ''origin/master''. If you have other changes that depend on the bug being fixed then rebase your work on that new branch.
 +
 
 +
Merge/Rebase: If you want your branch to include new commits from the remote repository, rebase your local branch. The reason for this is that in Gerrit, changes are reviewed one commit at a time, and modified until all review feedback has been addressed. This is different from a pull request workflow, where the combined changes are reviewed and feedback is addressed with additional commits.
  
 
== Coding standards ==  
 
== Coding standards ==  
Line 563: Line 661:
 
Eclipse has standards for how to write code.
 
Eclipse has standards for how to write code.
  
[[Coding conventions|Coding_Conventions]]
+
[[Coding_Conventions|Coding conventions]]
  
[[Use interface guidelines|User_Interface_Guidelines]]
+
[[User_Interface_Guidelines|Use interface guidelines]]
  
 
These documents have links to other document. Browse through them without expecting to learn everything, just so you know roughly what areas and types of details they covert. When you are
 
These documents have links to other document. Browse through them without expecting to learn everything, just so you know roughly what areas and types of details they covert. When you are
Line 572: Line 670:
  
 
In addition there is all the worlds collective knowledge on how to write programs that shine.
 
In addition there is all the worlds collective knowledge on how to write programs that shine.
When there is a conflict, the Eclipse guide lines and conventions take precedense.
+
When there is a conflict, the Eclipse guide lines and conventions take precedence.
  
 
Breaking the rules is ok if there is a very good reason and you can tell us what that reason
 
Breaking the rules is ok if there is a very good reason and you can tell us what that reason
Line 580: Line 678:
 
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a
 
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a
 
lot of slow Java code.
 
lot of slow Java code.
 +
 +
=== Braces for one-line statements ===
 +
 +
Before 3.7.0 both in JGit and EGit, the preferred coding style was to leave off braces around statements with one line (with some exceptions to this rule), e.g.:
 +
 +
if (condition)
 +
    doSomething();
 +
 +
Starting with 3.7.0 braces are mandatory independently on the number of lines, without exceptions. The old code will remain as is, but the new changes should use the style below:
 +
 +
if (condition) {
 +
    doSomething();
 +
}
 +
 +
The main reason to the change was to simplify the review process, coding guidelines and to make them more consistent with Eclipse code formatter, see {{bug|457592}}.
 +
 +
=== Removing trailing whitespace ===
 +
In JGit and EGit we have enabled the save action "Remove trailing white spaces on all lines" for Java sources. This works except for empty comment lines, see {{bug|414421}}.
 +
 +
As a workaround, use the following sequence of commands in the Java editor to trick the save action:
 +
* remove the offending trailing whitespace
 +
* the save action re-adds the trailing whitespace
 +
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without  triggering the save action again
 +
 +
Another workaround is to use [http://stackoverflow.com/questions/10413922/convert-spaces-to-tabs-in-lines-i-changed-in-a-commit?answertab=active#tab-top this little script] from the command line to edit away trailing whitespace from changed lines.
  
 
== Commit message guidelines  ==
 
== Commit message guidelines  ==
  
*The commit message header should fit on one line and should start with an uppercase letter
+
*The commit message header should fit on one line and should start with an uppercase letter. A blank line separates it from the body of the message.
*The commit message have newline characters after every 60-70 characters.  
+
*The first line should be a clear and concise description about the change and should not end with a dot.  
*Find more reasoning about commit message formatting in [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html "A Note About Git Commit Messages"]
+
*If a Gerrit Change-Id is available (for example when re-submitting to the same change), it should be added in the format below
+
*If there is an associated bug number in Bugzilla about it, it should come right before Gerrit's Change-Id entry (if available) or towards the end.
+
*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.
 
*Enter a newline before providing a more detailed description about the change.
 +
*Format the commit message to have newline characters after every 60-70 characters.
 +
*Find more reasoning about commit message formatting in [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html "A Note About Git Commit Messages"]
 +
*''Commit message footers'' (everything following the last blank line in the commit message) in ''Key: value'' format are used for additional commit meta data. Some tools especially ''Gerrit'' parse this meta data to provide additional functionality.
 +
**If there is an associated bug number in Bugzilla about it, it should come as a ''Bug:'' footer right before Gerrit's Change-Id entry (if available) or towards the end.
 +
**If a ''Contribution Questionnaire'' has been issued to initiate and track the review of contributed changes by the Eclipse Foundation's IP team the IPZilla bug number should be added as  ''CQ:'' footer in the format shown below
 +
**A ''Gerrit Change-Id'' footer is required for all changes pushed to Gerrit (to enable pushing new patchsets for the same change), it should be added in the format shown below. Use the [[EGit/Contributor_Guide#Install_the_commit-msg_hook_in_your_repository|Gerrit commit message hook or EGit]] to add the ''Change-Id''.
 +
**A "Signed-off-by" can be added at the end of the commit message (see example below). Note: at the moment this is not required but may be used to list all who modified (amended, rebased, cherry-picked) this change.
 +
 
<pre>Fix the commit dialog to respect the workbench's selection
 
<pre>Fix the commit dialog to respect the workbench's selection
  
Line 600: Line 726:
  
 
Bug: 12345
 
Bug: 12345
 +
CQ: 6031
 
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
 
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
 
Signed-off-by: Your Name <your.email@example.org>
 
Signed-off-by: Your Name <your.email@example.org>
 
</pre>
 
</pre>
 +
 +
== Copyright ==
 +
 +
When contributing patches, you have to update the copyright section at the beginning of the file if there is one. Please follow the style that is already present in the file. Some examples follow.
 +
 +
When there is only one copyright present (from a person or a company), like this:
 +
 +
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org>
 +
</pre>
 +
 +
Change it like this (notice the updated year):
 +
 +
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.
 +
</pre>
 +
 +
If there is a section <tt>Contributors:</tt> below the legal text and your change is more than a few lines, you can add your name there and optionally describe the change and link to a bug number. You can also start such a section if you contributed a significant change.
 +
 +
When there are multiple copyright entries there, add yours as a separate line. So, given this:
 +
 +
<pre>Copyright (C) 2010 Some Name <some@example.org>
 +
Copyright (C) 2011 Other Name <other@example.org>
 +
</pre>
 +
 +
Add another line:
 +
 +
<pre>Copyright (C) 2010 Some Name <some@example.org>
 +
Copyright (C) 2011 Other Name <other@example.org>
 +
Copyright (C) YEAR Your Name <you@example.org>
 +
</pre>
 +
 +
For new files, copy one of the existing headers and start the copyright section with your name.
 +
 +
Also see http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.
  
 
== Test before submitting ==
 
== Test before submitting ==
Line 609: Line 769:
  
 
* Run all existing tests. It does not take very long.
 
* Run all existing tests. It does not take very long.
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java5 and Eclipse 3.5. You cannot use API's that are newer. We often see breakages because Java 6 API's are used.
+
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 7 and Eclipse 3.8.2. You cannot use API's that are newer.
 
+
Note: In order to test in Eclipse 3.5 (Galileo), consider building EGit with the <code>platform-galileo</code> maven profile (see the [[#Maven Build Sequence]] for more details).
+
  
 
== Sending patches by mail  ==
 
== Sending patches by mail  ==
Line 619: Line 777:
 
If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.  
 
If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.  
  
'''However''', it's generally preferred that you send items which you want comments on via Gerrit as per [[#Adding_a_remote]], since Gerrit allows comments to be added in-line and allows the opportunity to send multiple versions of a patch after changes are made. Once a change has been submitted to Gerrit, you can then mail the developer mailing list with a request to review your change via URL or get Gerrit to send the mail on your behalf.
+
'''However''', it's generally preferred that you send items which you want comments on via Gerrit as per [[#Contributing_Patches]], since Gerrit allows comments to be added in-line and allows the opportunity to send multiple versions of a patch after changes are made. Once a change has been submitted to Gerrit, you can then mail the developer mailing list with a request to review your change via URL or get Gerrit to send the mail on your behalf.
  
 
<br/>
 
<br/>
Line 626: Line 784:
  
 
== Install the commit-msg hook in your repository  ==
 
== Install the commit-msg hook in your repository  ==
<pre style="width: 60em;">scp -p -P 29418 username@egit.eclipse.org:hooks/commit-msg .git/hooks/
+
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/
 
</pre>  
 
</pre>  
 
This will ask for a password. It is the password that you have to generate in the ''SSH Keys'' section of settings in your Gerrit account.
 
This will ask for a password. It is the password that you have to generate in the ''SSH Keys'' section of settings in your Gerrit account.
  
You can alternatively [http://egit.eclipse.org/r/tools/hooks/commit-msg download the file]. The [http://gerrit.googlecode.com/svn/documentation/2.1.2/cmd-hook-commit-msg.html hook] helps append a Change-Id to your commit message.
+
You can alternatively [https://git.eclipse.org/r/tools/hooks/commit-msg download the file]. The [http://gerrit.googlecode.com/svn/documentation/2.1.2/cmd-hook-commit-msg.html hook] helps append a Change-Id to your commit message.
 +
 
 +
EGit can also generate a Gerrit Change-Id into your commit message both [[EGit/User_Guide#Commit_Message|manually]] or in an [[EGit/User_Guide#Gerrit_Configuration|automated]] way.
  
 
== To create a new change  ==
 
== To create a new change  ==
  
 
*JGit
 
*JGit
<pre style="width: 60em;">git push ssh://username@egit.eclipse.org:29418/jgit.git HEAD:refs/for/master
+
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master
 
</pre>  
 
</pre>  
 
*EGit
 
*EGit
<pre style="width: 60em;">git push ssh://username@egit.eclipse.org:29418/egit.git HEAD:refs/for/master
+
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master
 
</pre>  
 
</pre>  
Or, if you've followed the instructions on [[#Adding_a_remote]] you can simply do:  
+
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do:  
 
<pre style="width: 60em;">git push review
 
<pre style="width: 60em;">git push review
 
</pre>  
 
</pre>  
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL  
+
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL
  
 
== To update an existing change with a new commit  ==
 
== To update an existing change with a new commit  ==
<pre style="width: 60em;">git push ssh://username@egit.eclipse.org:29418/egit.git HEAD:refs/for/master
+
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master
 
</pre>  
 
</pre>  
This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on [http://gerrit.googlecode.com/svn/documentation/2.0/user-changeid.html change-id lines] and [http://gerrit.googlecode.com/svn/documentation/2.0/user-upload.html#push_replace replacing changes].
+
This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on [https://git.eclipse.org/r/Documentation/user-changeid.html change-id lines] and [https://git.eclipse.org/r/Documentation/user-upload.html#push_replace replacing changes].
  
 
'''Note:''' To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).
 
'''Note:''' To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).
Line 656: Line 816:
 
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them.  
 
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them.  
  
If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, [http://egit.eclipse.org/r/2 http://egit.eclipse.org/r/2] shows the 'download' section for each patchset. In this case, it looks like:  
+
If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, [http://git.eclipse.org/r/2 http://git.eclipse.org/r/2] shows the 'download' section for each patchset. In this case, it looks like:  
  
*Patch Set 1 <code>git pull git://egit.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code>  
+
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code>  
*Patch Set 2 <code>git pull git://egit.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code>  
+
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code>  
*Patch Set 3 <code>git pull git://egit.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code>  
+
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code>  
*Patch Set 4 <code>git pull git://egit.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code>
+
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code>
  
 
Performing a <code>git pull</code> will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a <code>git fetch</code> instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again:  
 
Performing a <code>git pull</code> will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a <code>git fetch</code> instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again:  
<pre>git fetch git://egit.eclipse.org/jgit refs/changes/02/2/3
+
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3
git fetch git://egit.eclipse.org/jgit refs/changes/02/2/4
+
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4
  
 
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25
 
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25
Line 676: Line 836:
  
 
== To trigger Hudson build for a change ==
 
== To trigger Hudson build for a change ==
 +
We have build jobs '''jgit.gerrit''', '''egit.gerrit''' and '''egit-github.gerrit''' on https://hudson.eclipse.org/egit/ which are triggered automatically when a new change or a new patchset for an existing change is pushed for review. These jobs will comment on the respective change when the build is started and when it's finished and vote on the change according to the build and test results.
  
:*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page  
+
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.
:*Search for a change you'd like to build
+
Committers can manually trigger these jobs in the following way:
:*Select the patch set(s) you want to trigger
+
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page  
:*Press '''Trigger Selected''' button
+
*Search for a change you'd like to build
 +
*Select the patch set(s) you want to trigger
 +
*Press '''Trigger Selected''' button
 +
If you are not a committer and need to retrigger a build ask for that on the mailing list.
  
 
== To approve a change  ==
 
== To approve a change  ==
Line 689: Line 853:
 
== To add a reviewer  ==
 
== To add a reviewer  ==
  
Once you've pushed your commit to Gerrit for review, you can go to the web page (http://egit.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.  
+
Once you've pushed your commit to Gerrit for review, you can go to the web page (https://git.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.
 +
 
 +
It's usually not necessary to add any reviewers, it should be reviewed by the committers sooner or later. If this hasn't happened, you can look for people that did changes in the same area and add them as reviewers. It's also ok to comment on a change to "bump" its visibility.
  
 
== Code Review  ==
 
== Code Review  ==
Line 697: Line 863:
 
== IP Review  ==
 
== IP Review  ==
  
The IP review category indicates whether or not the change has been properly logged under the [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf eclipse IP process]. Under that process, any committer should mark his/her change +1 if they were the sole author of the change. For any other change, a committer should only mark +1 after ensuring the corresponding bug in Bugzilla has been updated with the iplog flag, or the corresponding CQ has been marked checkintocvs. For contributions from external contributors have a look at [http://www.eclipse.org/dsdp/tm/development/committer_howto.php#external_contrib the detailed rules]. A +1 vote is required to submit a change, while a -1 vote will block submission.
+
The IP review category indicates whether or not the change has been properly logged under the [http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf Eclipse IP Process]. Under that process, any committer should mark his/her change +1 if they were the sole author of the change. For any other change, a committer should only mark +1 after ensuring the [[#Legal_Paperwork|Legal Paperwork]] has been done. A +1 vote is required to submit a change, while a -1 vote will block submission.
  
 
== Submission Guidelines ==
 
== Submission Guidelines ==
Line 710: Line 876:
 
* if you want your changeset reviewed by someone, please add them as a reviewer
 
* if you want your changeset reviewed by someone, please add them as a reviewer
  
 +
== Tips & Tricks ==
 +
 +
=== Class Loading Issues ===
 +
 +
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:
 +
 +
Enable tracing in your launch configuration to get information how imported packages are resolved at runtime. Select the Tracing tab in your launch configuration, select "Enable tracing", select plug-in org.eclipse.osgi, select category resolver/wiring on the right side.
  
 
[[Category:Draft_Documentation]]
 
[[Category:Draft_Documentation]]

Revision as of 04:56, 26 August 2015

Contents

Communication

Channel JGit EGit
Developer Mailing List JGit developer mailing list EGit developer mailing list
Build Notices Mailing List JGit build notices mailing list EGit build notices mailing list
Reporting Bugs File new JGit bug File new EGit bug
User Forum EGit User Forum


Obtaining Sources

EGit and JGit are self hosted in Git. You can browse the repositories on the web: EGit, JGit

The first section below describes how to clone a repository and can be skipped if you have done this before.

The next section lists the repositories and their URLs.

Cloning

On the command line

git clone <enter URL>

After that, import the projects into Eclipse using Import > Existing Projects into Workspace.

Using EGit (see download page)

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

Then, clone the repository and import the projects:

  • Open File > Import... and select Git > Projects from Git
  • Selet URI
  • Enter the URL (see next section)
  • Import existing projects into the workspace from the newly created working directory

Repositories

To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed.

EGit

URL: https://git.eclipse.org/r/egit/egit.git

This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.

JGit

URL: https://git.eclipse.org/r/jgit/jgit.git

This is the Java implementation of Git used by EGit, for working with Git repositories.

EGit GitHub Integration

URL: https://git.eclipse.org/r/p/egit/egit-github.git

EGit also provides tools for integrating with GitHub and Mylyn tasks.

For getting the dependencies, open the file org.eclipse.mylyn.github-feature/github.target (view on web) and select Set as Target Platfrom.

EGit PDE Tools

URL: https://git.eclipse.org/r/egit/egit-pde.git

EGit also provides tools for integrating with PDE Build and Eclipse RelEng Tools. If you are an Eclipse developer using PDE Build and/or the Eclipse RelEng tools you might be interesting in the following as well. Otherwise you might just skip this section.

In addition to the dependencies required for JGit and EGit you also need Eclipse PDE (>= 3.6.1) as well as org.eclipse.releng.tools in your target platform or checked out from CVS in your workspaces.

Development IDE Configuration

Download and install the Eclipse package "Eclipse IDE for Eclipse Committers" or "Eclipse for RCP and RAP Developers" from here, if you don't already have it:

http://www.eclipse.org/downloads/

Tools

Note: You have to use at least Eclipse 4.3.2 (Kepler SR2), earlier versions had a bug where the following did not work (see bug 409073).

To install all the necessary tools to work on EGit/JGit, there is a egit-developer-tools.p2f file which you can use as follows:

  • File > Import > Install > Install Software Items from File
  • Browse...
    • Go to the location of your egit repository, open the tools directory and select egit-developer-tools.p2f
    • Alternatively, if you only want to contribute to JGit, download the file from the above link and select it
  • All the items you don't already have should be selected automatically
  • Finish the wizard
  • Restart

Java Requirements

EGit and JGit have Java 7.0 and Eclipse Platform 3.8.2 (Juno) as minimum requirements, so dependencies to newer Java and platform versions must be avoided.

We are using PDE/API Tools Environment Descriptions (see changes for JGit and EGit) to facilitate detecting code which isn't working on Java 7. If you followed the instructions in the Tools section above, the necessary descriptions should already be installed. Otherwise install PDE/API Tools Environment Descriptions from the release train repository, see Installing Execution Environment Descriptions.

Dependencies

After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies. There are a few ways to install these.

Option 1 (recommended): Use a Target Platform

EGit target platforms in org.eclipse.egit.target

This is the easiest method to install dependencies:

  • Open the org.eclipse.egit.target project
  • Choose the egit-<version>.target file matching the version of your Eclipse platform (e.g. 4.5 for Mars) and open it (this may take a while as it downloads the indexes of the p2 repositories the target platform refers to)
  • In the resulting editor, click on the Set as Target Platform link at the top right (this may also take a while since it downloads the dependencies)

After that, the workspace should build cleanly. If not, try Project > Clean... > All. If this also doesn't help open Preferences > Plug-In Development > Target Platform, select the checked target platform and click "Reload..." this will flush PDE's bundle cache and re-download the artifacts listed in the target platform.

There are different target definitions, one for each version of Eclipse that EGit supports. The one you select will be the one that is started if you want to try out a feature or bug fix.

You can always switch between them to test on different Eclipse versions. E.g. when you are developing some major UI functionality, you should try it with the oldest supported Eclipse release to make sure it doesn't depend on API that is only available in later versions.

Option 2: Install from Orbit P2 Repository

Install the dependencies from the Orbit p2 repository by importing the p2f file described above.

If you want to try another Orbit p2 repository version on the Orbit Downloads page, click on the newest recommended build (R-Build) and copy the update site link from "Orbit Build Repository" (it should end with /repository). Add this update site in Eclipse using "Install New Software..." and then find and select the following entries:

  • Java Mocking and Stubbing Framework
  • Args4j
  • Protocol Buffers
  • Apache Jakarta log4j Plug-in
  • Apache Commons Compress
  • XZ Data Compression
  • Hamcrest Library of Matchers
  • JavaEWAH

Running

Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:

  • Right click on the org.eclipse.egit.ui project
  • Debug As > Eclipse Application

This should create a new launch configuration and start a new nested Eclipse instance in debug mode. The created launch configuration can be edited, e.g. to change where the workspace of the nested Eclipse should be located.

The launch configuration can also be used in normal (non-debug) mode of course.

Also see the reference on eclipse application launchers.


Builds

The central EGit and JGit builds run on the JGit/EGit Hudson instance

Prerequisites for the Maven build are

Hudson

JGit

  • JGit can be built using Maven 2 or 3.
  • use Java 7 to run the JGit Maven build (required since bundle org.eclipse.jgit.java7 needs Java 7)
  • JGit packaging projects (Eclipse feature and update site) are built using Maven 3 and Tycho.

EGit

  • EGit is built using Maven 3 and Tycho.

Mailing Lists

If you're interested in following builds, please check out the following mailing lists:

Maven Build Sequence

  • Due to a current limitation of Tycho it is not possible to mix pom-first and manifest-first builds in the same reactor build hence the pom-first JGit build has to run separately before the build for the manifest-first JGit packaging project.
  • The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.
  • To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html

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

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

[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install
[INFO] Scanning for projects...
...

[~/src/jgit] $ cd ../egit

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

The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes that egit and jgit source trees are located under a common parent folder. If this is not the case the path to the jgit p2 repository has to be injected via system property:

[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/org.eclipse.jgit.updatesite/target/site

The hudson build on build.eclipse.org uses (for SNAPSHOT builds):

[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/
                     org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/

If you wan to build EGit for the specific Juno platform, consider using the platform-juno maven profile:

[~/src/egit] $ mvn -P platform-juno clean install

For EGit version 3.0, platform-juno (Eclipse 4.2) and platform-kepler (Eclipse 4.3) are available. In addition platform-kepler-staging refers to the Kepler staging repository.

Upon a successful build, a p2 update site should be generated inside egit/org.eclipse.egit.repository/target/repository. If not, make sure the target platform has been downloaded from within Eclipse (Windows>Preferences>Plug-in Development>Target Platform). The default target platform defined in the maven build is currently Eclipse 4.3.

FindBugs and PMD

As part of the build, JGit and EGit run FindBugs and PMD to find issues.

Checking for JGit API Changes using API Baseline

The JGit projects have API tooling enabled. In order to use PDE API tools to get assistance with maintaining API changes and additions you need to set an API baseline:

  • download the p2 repository for the latest EGit release (which includes the JGit artifacts) to a local folder, e.g. ~/egit-releases/updates-4.0, find the p2 repository URLs here and download the p2 repository of the latest minor release (service releases don't change API) using the corresponding link in the last column of that table
  • in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.0) and point it to the local copy of the corresponding EGit p2 repository.
  • the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems
  • see the PDE API Tools User Guide for more details.

Automated Signing and Publishing

EGit and JGit builds running on the JGit/EGit Hudson are automatically signed (using the CBI eclipse-jarsigner-plugin) and published to the folder

master branch:         /home/data/httpd/download.eclipse.org/egit/updates-nightly
latest stable branch:  /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly
  • To enable signing the maven profile eclipse-sign must be enabled via the option -P eclipse-sign in the respective build jobs running at https://hudson.eclipse.org/egit/
  • To enable publishing to download.eclipse.org the maven profile publish must be enabled via the option -P publish in the egit build job.

Signing (old method, replaced by automated procedure)

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

At the moment, Chris Aniszczyk (caniszczyk) and Matthias Sohn (msohn) have 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.

Contribution to Release Train

The release train contribution for JGit and EGit is maintained in the git repository

ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git

in the file

egit.b3aggrcon

The release train build is coordinated on the cross-project-issues-dev mailing list


Documentation

JGit

The JGit project generates a project report and javadocs using a Maven site. This Maven site is deployed to http://download.eclipse.org/jgit/site/${project.version}. E.g. http://download.eclipse.org/jgit/site/3.5.0.201409260305-r/

Generating the site:

$ mvn site:site

Staging the site locally under ./target/staging:

$ mvn site:stage

If you can connect to build.eclipse.org over ssh (ask webmaster if you are a committer and need ssh access) you can deploy a local build of the site:

$ mvn site:deploy

The site is deployed under http://download.eclipse.org/jgit/site/${project.version}

To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:

<server>
     <id>jgit.website</id>
     <username>username</username>
     <privateKey>${user.home}/.ssh/id_rsa</privateKey>
     <filePermissions>664</filePermission>
     <directoryPermissions>775</directoryPermissions>
     <configuration></configuration>
</server>

To deploy the site from EGit HIPP (Hudson) at https://hudson.eclipse.org/egit/ enable the Maven profile build-server and add the Maven goals site:site site:deploy.

If you uploaded the site for a new release update the index /home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html to refer to the new release's site.

EGit

The EGit project sources its documentation from the wiki and generates Eclipse help content from it (under the covers, we are using Mylyn WikiText to make this possible). This significantly lowers the barrier for people to contribute documentation to the EGit project. To contribute documentation, simply modify the EGit User's Guide. Have a look at the Style Guidelines and Eclipse Documentation Style Guide to get some guidance on how to write good documentation. More on that can be found here.

The documentation is contained in the org.eclipse.egit.doc plug-in. The build-help.xml drives the generation of the help content. It is integrated into the maven build. The regular maven build of org.eclipse.egit.doc

$ mvn clean install 

will only package the help content committed to the egit repository. To update the help content by downloading the latest documentation from the wiki run

$ mvn clean install -Dupdate.egit.doc

Don't forget to check all the generated help pages and especially all hyperlinks and images before pushing the updated help to the code review system for inclusion into the continuous build.

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 egit-dev mailing list.


Tests

JGit Unit Tests

The JGit unit tests are executed during the maven build. To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.

JGit HTTP Tests

The JGit HTTP tests in org.eclipse.jgit.http.test rely on the Jetty web container.

To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in dependencies.

Alternatively, install "Jetty 9.2.10.v20150310" from http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.10.v20150310/

EGit Core Tests

The EGit Core tests are executed during the maven build for the bundle org.eclipse.egit.core.test.

To run them from the Eclipse workbench use the launch configuration which is part of the sources of the test bundle org.eclipse.egit.core.test.

EGit UI Tests

The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.

You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":

Starting a UI test from Eclipse:

  • select the test class or test method
  • click Run As > SWTBot Test

Start-swtbot-test.png

Do not touch the mouse or keyboard when the UI test is running since this may disturb the UI test by e.g. moving the current focus to another window.

During Maven Build

The tests are executed in the integration-test phase of the default Maven lifecycle.

If you want to skip execution of UI tests (only execute core tests):

mvn -P skip-ui-tests clean install

If you want to skip all tests:

mvn clean install -Dmaven.test.skip=true

Auxilary testing tools

Any code, including testing code, does not always do what you expected it to. The most common failure is probably the failure to actually execute the part of the code you wanted to test. Code coverage tools like EclEmma can easily visualize what part of the code is being executed.

Bugs

If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":

EGit bugs with helpwanted or bugday

JGit bugs with helpwanted or bugday

Links

Filing Bugs

How to file bugs

File a bug

Bug Reports and Links

Trends (bugs and enhancements) EGit JGit
Open by component (date range editable) Open Open
Open by status Open Open
Assigned Assigned Assigned
Open and closed by status All All
Lists EGit JGit
Unresolved for passed target milestones Open Open
Open bugs Open Open
Open enhancements Open Open
Bugs with votes With Votes With Votes
Assigned bugs and enhancements Assigned Assigned
Reports EGit and JGit
Open EGit and JGit bugs Open
Assigned EGit and JGit bugs Assigned
New bugs opened Last day Last week Last month Last year
Bugs closed Last day Last week Last month Last year


To get notified of bugs, go to your e-mail preferences and add <product>.<component>-inbox@eclipse.org to your watch list. For example to get notified of EGit UI bugs, add egit.ui-inbox@eclipse.org.

Keywords

To simplify bug management we started to tag EGit bugs with additional pseudo keywords (not normal Bugzilla keywords). The tags are prepended to the bug's summary field. Since we use these tags for internal bug management reporters of a bug should not add any pseudo keywords when filing the bug. The owner of the component bucket is responsible to add the keywords.

Keywords are used to group bugs without assigning them to a developer. So with the introduction of the keywords it is easy to search for all bugs belonging to a specific sub component. For example to get an overview of all open refactoring issues search for new, assigned or reopened bugs containing the word [refactoring] in the summary field.

Be aware that not all bugs are tagged with keywords, only bugs that belong to a certain sub group may have a tag attached. The following lists some of the currently used tags.

Tag Description Link
[sync] everything related to Synchronize / Synchronize View View bugs
[repoView] everything related to the Git Repository View View bugs
[releng] everything related to release engineering and build View bugs
[historyView] everything related to the Git History View View bugs


Website

The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.

egit

jgit


Contributing Patches

Using Gerrit at Eclipse

EGit and JGit projects are using Gerrit Code Review for Git based patch submission and review.

Parts of this chapter are also available in the Eclipse Gerrit wiki.

User Account

  • In order to contribute you need an Eclipse user account on eclipse.org, on creation of a new account you must agree to the Contributor Agreement.

Legal Paperwork

Before your first contribution can be accepted, you need to electronically sign the Eclipse Foundation Contributor License Agreement (CLA). You only have to do this once, and it covers all Eclipse projects. The new process was discussed in bug 381105 and introduced on June 27, 2013.

Minimally, all Git commits you contribute must have the following:

  • A single line summary in the comment field, followed by a more detailed descriptive paragraph;
  • Your credentials (email address) captured in the "Author" field; and
  • A "Signed-off-by" entry with matching credentials in the comment.
  • The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the Certificate of Origin.

In addition ensure

  • that the contributed code is licensed under the project license (EPL for EGit and EDL for JGit). This is done by putting a copyright and license header into every new java file. See other existing project source files for the correct content.

With a valid CLA on file, the signed-off commit and the copyright and license header in place, we will be able to accept small patches (<1000 LoC) immediately. For larger patches, we will also have to create a contribution questionnaire for review by the Eclipse IP team, but this usually doesn't require additional actions from you.

To verify whether a contribution requires a CQ, use one of the following git commands to check:

  • If it's committed: git log --shortstat
  • If not committed: git diff --stat

These commands tell you the number of insertions(+), and deletions(-). If the total number of lines inserted (e.g. added) in a contribution is greater than 1000 (yes, this includes comments) then a CQ is required.

Find more details about how to contribute in Contributing via Git (for contributors) and Handling Git Contributions (for committers).

Logon

Gerrit Web UI

Logon to the Gerrit Web UI at https://git.eclipse.org/r/ using the email address you registered with your Eclipse (and Bugzilla) account and your Eclipse password.

Git over SSH

When accessing Gerrit over SSH from git or EGit use the username displayed here and upload your public SSH key to Gerrit here.

Gerrit SSH URl: ssh://username@git.eclipse.org:29418/egit/egit.git

Git over HTTPS

When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed here

Gerrit HTTPS URl: https://git.eclipse.org/r/p/egit/egit.git

SSH Keys

  • Add one or more public SSH keys to Gerrit here.
  • If you are absolutely certain you do not have keys already, you must create a public and private pair of SSH keys. It is strongly recommended that you use a passphrase.
  • Generating SSH key pair on command line
ssh-keygen -t rsa -C "your_email@youremail.com"
  • Execute SSH once to accept the host key (or copy it from the registration web page)
ssh -p 29418 username@git.eclipse.org

Doing Code Reviews with Gerrit

Using Gerrit with git command line:

  • Upload your patch from Git to the target project:

JGit

git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master

EGit

git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master

Adding a dedicated remote

Since git can have multiple remotes, you can define one to be used to refer to Gerrit to save typing. Inside a previously checked-out repository you can run:

cd path/to/jgit
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git
git config remote.review.push HEAD:refs/for/master

cd path/to/egit 
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git
git config remote.review.push HEAD:refs/for/master

You can now submit review requests from either repository using:

git push review

Using Gerrit with EGit:

Eclipse will look for your private key in the SSH2 Home location specified in the General>Network Connections>SSH2 Preference Page. If your id_rsa private key makes use of the AES-128-CBC algorithm (view the file as text to confirm), Eclipse will need at least com.jcraft.jsch 0.1.44 to make use of it.

  • Clone the JGit and EGit repositories and select Gerrit Configuration... in the context menu of the remote "origin" in the Git Repositories view to configure pushing to the code review queue.
  • Alternative approach: Add a new review remote in the Git Repositories view and select Gerrit Configuration... in the context menu of the remote
    • From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, review is suggested.
    • Changes committed to your local clone can now be pushed to Gerrit using the review Remote. You will be prompted for your private key's passphrase if Eclipse is looking for it in the right place.
  • Instead of using the Gerrit Configuration... wizard you can do the configuration steps manually:

Using the Mylyn Gerrit Connector

The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.

It contains several useful features:

  • Cloning from Gerrit and automatic configuration
    • The wizards "Import Projects from Git" and "Clone Git Repository" will offer the possibility to browse the list of repositories on Gerrit servers and to clone selected repositories. After cloning the Gerrit configuration will be done automatically.
  • Importing Gerrit changes as Mylyn tasks
  • Fetching patch sets directly from the task editor
  • Reviewing changes in the task editor
  • Submitting changes from the task editor

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.

Branches

When working with Gerrit, you can create local branches as you wish. When you are ready to push your changes, only the commits from your branch are pushed and are converted to reviews on Gerrit. The branch name itself is not visible on Gerrit.

Do not mix unrelated changes in branches: When you encounter a bug while working on something then create a new branch to fix the bug. Make sure you base it on the state of the remote branch that you want your fix to go to, e.g. origin/master. If you have other changes that depend on the bug being fixed then rebase your work on that new branch.

Merge/Rebase: If you want your branch to include new commits from the remote repository, rebase your local branch. The reason for this is that in Gerrit, changes are reviewed one commit at a time, and modified until all review feedback has been addressed. This is different from a pull request workflow, where the combined changes are reviewed and feedback is addressed with additional commits.

Coding standards

Eclipse has standards for how to write code.

Coding conventions

Use interface guidelines

These documents have links to other document. Browse through them without expecting to learn everything, just so you know roughly what areas and types of details they covert. When you are not sure about how to write a piece of code or design the user interface, these are the two first places to look at.

In addition there is all the worlds collective knowledge on how to write programs that shine. When there is a conflict, the Eclipse guide lines and conventions take precedence.

Breaking the rules is ok if there is a very good reason and you can tell us what that reason is.

In addition to these general rules, we regard performance high. If the EGit plugin is slow in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a lot of slow Java code.

Braces for one-line statements

Before 3.7.0 both in JGit and EGit, the preferred coding style was to leave off braces around statements with one line (with some exceptions to this rule), e.g.:

if (condition)
    doSomething();

Starting with 3.7.0 braces are mandatory independently on the number of lines, without exceptions. The old code will remain as is, but the new changes should use the style below:

if (condition) {
    doSomething();
}

The main reason to the change was to simplify the review process, coding guidelines and to make them more consistent with Eclipse code formatter, see bug 457592.

Removing trailing whitespace

In JGit and EGit we have enabled the save action "Remove trailing white spaces on all lines" for Java sources. This works except for empty comment lines, see bug 414421.

As a workaround, use the following sequence of commands in the Java editor to trick the save action:

  • remove the offending trailing whitespace
  • the save action re-adds the trailing whitespace
  • CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again

Another workaround is to use this little script from the command line to edit away trailing whitespace from changed lines.

Commit message guidelines

  • The commit message header should fit on one line and should start with an uppercase letter. A blank line separates it from the body of the message.
  • The first line should be a clear and concise description about the change and should not end with a dot.
  • Enter a newline before providing a more detailed description about the change.
  • Format the commit message to have newline characters after every 60-70 characters.
  • Find more reasoning about commit message formatting in "A Note About Git Commit Messages"
  • Commit message footers (everything following the last blank line in the commit message) in Key: value format are used for additional commit meta data. Some tools especially Gerrit parse this meta data to provide additional functionality.
    • If there is an associated bug number in Bugzilla about it, it should come as a Bug: footer right before Gerrit's Change-Id entry (if available) or towards the end.
    • If a Contribution Questionnaire has been issued to initiate and track the review of contributed changes by the Eclipse Foundation's IP team the IPZilla bug number should be added as CQ: footer in the format shown below
    • A Gerrit Change-Id footer is required for all changes pushed to Gerrit (to enable pushing new patchsets for the same change), it should be added in the format shown below. Use the Gerrit commit message hook or EGit to add the Change-Id.
    • A "Signed-off-by" can be added at the end of the commit message (see example below). Note: at the moment this is not required but may be used to list all who modified (amended, rebased, cherry-picked) this 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
CQ: 6031
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a
Signed-off-by: Your Name <your.email@example.org>

Copyright

When contributing patches, you have to update the copyright section at the beginning of the file if there is one. Please follow the style that is already present in the file. Some examples follow.

When there is only one copyright present (from a person or a company), like this:

Copyright (C) 2010, 2011 Some Name <some@example.org>

Change it like this (notice the updated year):

Copyright (C) 2010, YEAR Some Name <some@example.org> and others.

If there is a section Contributors: below the legal text and your change is more than a few lines, you can add your name there and optionally describe the change and link to a bug number. You can also start such a section if you contributed a significant change.

When there are multiple copyright entries there, add yours as a separate line. So, given this:

Copyright (C) 2010 Some Name <some@example.org>
Copyright (C) 2011 Other Name <other@example.org>

Add another line:

Copyright (C) 2010 Some Name <some@example.org>
Copyright (C) 2011 Other Name <other@example.org>
Copyright (C) YEAR Your Name <you@example.org>

For new files, copy one of the existing headers and start the copyright section with your name.

Also see http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.

Test before submitting

See the #Manual alpha testing section for some advice about how to test you work yourself.

  • Run all existing tests. It does not take very long.
  • Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 7 and Eclipse 3.8.2. You cannot use API's that are newer.

Sending patches by mail

Although sending patches by mail is the approved way of interacting with, and asking feedback from, the Git project, please don't send patches via git send-email. Instead, please use git format-patch to generate the mbox, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides.

If you're sending a work-in-progress for a review, be aware that you can also attach work-in-progress (or RFC) items to Bugzilla; it's not just for finished patches.

However, it's generally preferred that you send items which you want comments on via Gerrit as per #Contributing_Patches, since Gerrit allows comments to be added in-line and allows the opportunity to send multiple versions of a patch after changes are made. Once a change has been submitted to Gerrit, you can then mail the developer mailing list with a request to review your change via URL or get Gerrit to send the mail on your behalf.


Gerrit Code Review Cheatsheet

Install the commit-msg hook in your repository

scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/

This will ask for a password. It is the password that you have to generate in the SSH Keys section of settings in your Gerrit account.

You can alternatively download the file. The hook helps append a Change-Id to your commit message.

EGit can also generate a Gerrit Change-Id into your commit message both manually or in an automated way.

To create a new change

  • JGit
git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master
  • EGit
git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master

Or, if you've followed the instructions on #Adding_a_dedicated_remote you can simply do:

git push review

Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL

To update an existing change with a new commit

git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master

This works because Gerrit links the new commit to the prior change based upon the Change-Id footer in the commit message. (This is automatically generated by the commit-msg hook you installed above.) If you refuse to use the commit-msg hook, or don't have a Change-Id footer, you should read the Gerrit documentation on change-id lines and replacing changes.

Note: To be picked up by Gerrit, a Change-Id line must be in the bottom portion (last paragraph) of a commit message, and may be mixed together with the Signed-off-by, Acked-by, or other such footers. So if your Change-Id line is ignored it's probably not in the last paragraph :).

To compare bulk diffs using Git

Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them.

If you've got a large changeset, and you want to be able to do diffs between them via (command line) git instead of browsing on the web, then you can fetch the individual changes and then perform a diff. For example, http://git.eclipse.org/r/2 shows the 'download' section for each patchset. In this case, it looks like:

Performing a git pull will both get the bits and merge them into your tree, which won't do what you want for comparison. So, in order to get the bits (but not merge), you need to do a git fetch instead. Let's say we want to diff the last two patches against each other rather than reviewing the entire patchset again:

git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4

git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25

# or git diff d14cc6 43de8d

If you're doing this from within an already checked out project, you can do git fetch origin (or any other remote name in .git/config}.

Git fetched data will stay around in your repository, but will be 'orphaned' if no references point to it. To clean up, you can run git gc or wait until this happens automatically.

To trigger Hudson build for a change

We have build jobs jgit.gerrit, egit.gerrit and egit-github.gerrit on https://hudson.eclipse.org/egit/ which are triggered automatically when a new change or a new patchset for an existing change is pushed for review. These jobs will comment on the respective change when the build is started and when it's finished and vote on the change according to the build and test results.

Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem. Committers can manually trigger these jobs in the following way:

  • Go to Trigger a Gerrit event manually page
  • Search for a change you'd like to build
  • Select the patch set(s) you want to trigger
  • Press Trigger Selected button

If you are not a committer and need to retrigger a build ask for that on the mailing list.

To approve a change

  • Click on Publish Comments
  • Vote with the radio buttons

To add a reviewer

Once you've pushed your commit to Gerrit for review, you can go to the web page (https://git.eclipse.org/r/) and see your changes. By clicking on the review, there's an option to add a reviewer by e-mail address; they'll then be sent a message indicating that they'd like your review on the item.

It's usually not necessary to add any reviewers, it should be reviewed by the committers sooner or later. If this hasn't happened, you can look for people that did changes in the same area and add them as reviewers. It's also ok to comment on a change to "bump" its visibility.

Code Review

The code review category indicates your opinion on the quality of the code, and how well it fits within the purpose of the existing surrounding code. A +2 vote from any committer is required before submission can occur. A -2 vote from any committer will block submission.

IP Review

The IP review category indicates whether or not the change has been properly logged under the Eclipse IP Process. Under that process, any committer should mark his/her change +1 if they were the sole author of the change. For any other change, a committer should only mark +1 after ensuring the Legal Paperwork has been done. A +1 vote is required to submit a change, while a -1 vote will block submission.

Submission Guidelines

We strive to use Gerrit to improve our understanding of the code base and improve quality.

In order to ensure a proper review happens, some simple guidelines should be followed:

  • vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;
  • If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know
  • let non-trivial changes be in review for at least 24 hours
  • if you want your changeset reviewed by someone, please add them as a reviewer

Tips & Tricks

Class Loading Issues

If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:

Enable tracing in your launch configuration to get information how imported packages are resolved at runtime. Select the Tracing tab in your launch configuration, select "Enable tracing", select plug-in org.eclipse.osgi, select category resolver/wiring on the right side.

Back to the top