https://wiki.eclipse.org/api.php?action=feedcontributions&user=Michael.keppler.gmx.de&feedformat=atomEclipsepedia - User contributions [en]2024-03-29T11:37:05ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/6.1&diff=445192EGit/New and Noteworthy/6.12022-03-21T14:42:39Z<p>Michael.keppler.gmx.de: /* EGit */</p>
<hr />
<div>= EGit =<br />
<br />
== Commit Messages ==<br />
<br />
EGit 6.1 has full support for git config <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-commitcleanup commit.cleanup]</tt>. This '''changes the behavior''' in the UI from previous EGit versions. Previously, EGit used the text the user entered as-is as commit message (except when squashing commits, where it did already remove comment lines). EGit 6.1 now always cleans up commit messages as specified by the git config <tt>commit.cleanup</tt>. The default setting is "strip", which means to remove comment lines, trailing whitespace, leading and trailing empty lines, and to collapse multiple consecutive empty lines to a single one.<br />
<br />
A ''comment line'' in a commit message is a line that has a <tt>#</tt> as the first non-whitespace character. Beware of this if you have the habit to start commit message lines with a hash (for instance, to use an issue reference of Github or similar git servers): A commit message line like "<tt>#123 Fix the furtible gobble</tt>" is a ''comment line'' and will be removed! To avoid this, let the line start with some other character, for instance, write "<tt>Issue #123: ...</tt>" or "<tt>[#123] ...</tt>", or place the issue number at the end. (Or on Github, don't put the issue number in the commit title at all and have a body line like "<tt>Fixes #123</tt>", which on Github [https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword will close the issue when the commit is merged].)<br />
<br />
EGit 6.1 comes with two UI features to help users with this behavioral change. First, wherever the user can edit a commit message, comment lines are colored differently.<br />
<br />
[[File:EGit 6.1 Commit Message Comment.png |alt="Colored comment lines in a commit message in EGit 6.1"]]<br />
<br />
The green lines are comments, and will be removed before making the commit. The color is configurable in the color preferences of Eclipse at ''Preferences&rarr;General&rarr;Appearance&rarr;Colors and Fonts'' in the "Git" section.<br />
<br />
Second, there is a new "preview" button for the commit message. When activated, it shows a read-only view of the final commit message.<br />
<br />
[[File:EGit 6.1 Commit Message Preview.png|alt="The commit message preview shows the final commit message, with comment lines removed."]]<br />
<br />
This preview shows the final verbatim commit message that will be used. (A Gerrit Change-Id of all zeroes will still be replaced upon commit.)<br />
<br />
:'''Note:''' EGit and JGit 6.1 only recognize the comment character <tt>#</tt>. The git config <tt>core.commentChar</tt> is not implemented yet.<br />
<br />
== Fetching Pull Requests ==<br />
<br />
Fetching pull requests has been enabled also for [https://gitea.com Gitea] servers. By default, the command ''Fetch Gitea Pull Request...'' is enabled if the host of a remote URI is "gitea.com". For self-hosted installations running at other host names, define custom host name patterns at ''Preferences&rarr;Version Control (Team)&rarr;Git&rarr;Servers''.<br />
<br />
== Git Repositories View ==<br />
<br />
The ''Open in Commit Viewer'' command is now also available on branches and tags shown in the Git Repositories view.<br />
<br />
== Git Staging View ==<br />
<br />
=== ''Commit & Push'' ===<br />
<br />
The ''Commit & Push'' button in the Git Staging view newly also takes into account the <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtmerge branch.&lt;name>.merge]</tt> git configuration. This configuration defines an upstream branch to push to; if not set, EGit will push to an upstream branch with the same name as the currently checked-out local branch. ''Commit & Push'' also ensures that it only pushes the currently checked-out branch, even if the git remote configuration has a push Refspec that would result in pushing several branches.<br />
: The push is done as if the ''Push Branch...'' dialog were run with its default settings: the remote to push to is determined normally via git configs <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtpushRemote branch.&lt;name>.pushRemote]</tt>, <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-remotepushDefault remote.pushDefault]</tt>, <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtremote branch.&lt;name>.remote]</tt>, "<tt>origin</tt>"; the upstream branch to push to is determined by <tt>branch.&lt;name>.merge</tt> or, if that is not set, by the name of the local branch.<br />
<br />
=== Hiding Untracked Files ===<br />
<br />
The view of the unstaged files has a new button to show or hide untracked files:<br />
<br />
[[File:EGit 6.1 Show Untracked.png|alt="Screenshot of the unstaged files viewer with the new button highlighted."]]<br />
<br />
By default, untracked files are shown. When the button is selected, untracked files are hidden.<br />
<br />
[[File:EGit 6.1 Hide Untracked.png|alt="Screenshot of the unstaged files viewer with unstaged files hidden."]]<br />
<br />
The title of the unstaged view shows the number of visible items and the total number of items, for instance, "(1/2)": one file of two is visible, one is filtered out from the view.<br />
<br />
When the input for the Git Staging view changes to a different repository, the button is reset and untracked files are shown again.<br />
<br />
== ''Push to Upstream'' ==<br />
<br />
The ''Push to Upstream'' command has been improved to take into account more of the git configuration to figure out what to push where. <br />
<br />
:'''Note''': in the UI, the command is frequently shown as <em>Push to 'origin'</em> in the context menus. Its label adapts to show the name of the [https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes git remote configuration] it'll use for pushing.<br />
<br />
Previously, it would push either whatever was defined in git config <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegtpush remote.&lt;name>.push]</tt>, or if nothing was configured there, it would push the current branch to an upstream branch of the same name.<br />
<br />
This behavior was sometimes a bit strange. First, if the remote had a push [https://git-scm.com/book/en/v2/Git-Internals-The-Refspec Refspec] with wildcards (or several push refspecs), the command would push several branches, not just the currently checked out branch. Second, if the currently checked out branch did have an upstream branch configured vis git config <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtmerge branch.&lt;name>.merge]</tt>, this was not honored.<br />
<br />
In EGit 6.1, the ''Push to Upstream'' command now considers also git configs <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-branchltnamegtpushRemote branch.&lt;name>.pushRemote]</tt> and <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-remotepushDefault remote.pushDefault]</tt>, and also <tt>[https://git-scm.com/docs/git-config#Documentation/git-config.txt-pushdefault push.default]</tt>. If <tt>push.default</tt> is "simple" (which is the git default) or "upstream", it will also honor a <tt>branch.&lt;name>.merge</tt> configuration (unless the remote has a push Refspec, which takes precedence).<br />
<br />
The command newly shows a dialog to configure the push if the git configuration for pushing is incomplete or ambiguous. It also shows a warning dialog when the git configuration would result in more than one branch being pushed.<br />
<br />
The ''Push to Upstream'' command corresponds to a simple '''<tt>git push</tt>''' on the command-line. To perform the equivalent of '''<tt>git push &lt;remote> &lt;branch></tt>''', use the ''Push Branch...'' command.<br />
<br />
== SSH Agent Support ==<br />
<br />
On Windows, JGit 6.1 supports not only Pageant or gpg-agent running in Pageant mode, but newly also Win32-OpenSSH, the OpenSSH port from Microsoft that is included in modern Windows.<br />
<br />
EGit 6.1 on Windows has an enhanced SSH agent preference where the user can define which SSH agent, if running, should be used by default if nothing is specified via the <tt>IdentityAgent</tt> setting in the SSH configuration file <tt>~/.ssh/config</tt>.<br />
<br />
[[File:EGit 6.1 Win SSH Agent Preferences.png|alt="Screenshot of the EGit preferences with the default SSH agent selector available on Windows highlighted"]]<br />
<br />
Note that the choice between "Pageant" and "Win32-OpenSSH" applies only if the SSH configuration file doesn't specify anything else; it can be overridden by the <tt>IdentityAgent</tt> configuration setting. The setting for "Use SSH agent for SSH connections", on the other hand, is a global master switch, and switches off SSH agent use no matter what the SSH configuration file says. SSH configurations related to SSH agents are considered only if this setting is switched on.<br />
<br />
On Linux or OS X, the choice preference is not shown since there is only one communication mechanism with SSH agents (via a Unix domain socket, normally provided via environment variable <tt>SSH_AUTH_SOCK</tt>). Using this environment variable is the single default.<br />
<br />
See also the [[JGit/New_and_Noteworthy/6.1#SSH|JGit description of SSH agent support]] for additional details.<br />
<br />
== Other Changes ==<br />
<br />
The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/6.1/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following 5 developers worked on this release:<br />
<br />
Gayan Perera,<br />
Julian Ruppel,<br />
Matthias Sohn,<br />
Nis Wechselberg,<br />
Thomas Wolf<br />
<br />
= Video =<br />
<br />
You can see the UI changes in action in the [https://youtu.be/GnNnQY5ujFg?t=619 Eclipse 2022-03 Java IDE Improvements] video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/6.1|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Tycho/Target_Platform&diff=442138Tycho/Target Platform2021-01-07T09:53:58Z<p>Michael.keppler.gmx.de: /* Browsing a p2 repository */</p>
<hr />
<div>The target platform is the set of artifacts from which Tycho resolves the project's dependencies. <br />
<br />
Background: OSGi allows to specify dependencies with version ranges and package dependencies (<tt>Import-Package</tt>). These dependencies (intentionally) do not map to unique artifacts. In order to pick a set of concrete bundles to be used for compilation, test execution, and assembly, Tycho needs a set of candidate artifacts which may be used to match the dependencies. This list of candidate artifacts is called the "target platform". The process of selecting artifacts from the target platform according to the project's dependencies is called "dependency resolution".<br />
<br />
There are different ways to define the content of the target platform; the most common ones are repositories with layout=p2 in the POM, which add entire p2 repositories to the target platform, or target definition files for more fine-grained control.<br />
<br />
== Which approach shall I use for the target platform of my project? ==<br />
<br />
There are a few different ways to configure a target platform in Tycho. These rules of thumb should help you to pick the right approach for your project:<br />
# If you are already using a target file in Eclipse, and that target file only contains "Software Site" locations (i.e. <tt>location</tt> elements with <tt>type="InstallableUnit"</tt>), use that target file for the Tycho build. This approach is the only way to share the same target platform configuration between Tycho and Eclipse.<br />
# If you want to get your Tycho build up and running quickly, just configure the needed p2 repositories in the POM and have Tycho pick anything required from these repositories. A good starting point should be to add one of the [[Eclipse Project Update Sites#Simultaneous_Release_repositories|Simultaneous Release repositories]].<br />
# If you want to exert control over the which bundles/bundle versions may be used by the build, use a target file and have it select the sub-set of features and bundles from a p2 repository that you want. Using a target file instead of p2 repositories in the POM may also speed up the build because fewer bundles in the target platform will often lead to a faster dependency resolution.<br />
<br />
== Target platform configuration ==<br />
<br />
The target platform is defined through POM configuration (see details below). Each module has its own target platform, although with the normal configuration inheritance in Maven, the target platform configurations are usually the same across multiple modules.<br />
<br />
<div id="Layout_p2"><br />
=== Simple target platform configuration ===<br />
<br />
In order allow Tycho to resolve the project dependencies against anything from a specific p2 repository, add that repository in the <tt>&lt;repositories&gt;</tt> section of the POM. Example:<br />
<pre><br />
<repository><br />
<id>eclipse-indigo</id><br />
<url>http://download.eclipse.org/releases/indigo</url><br />
<layout>p2</layout><br />
</repository><br />
</pre><br />
<br />
In terms of the target platform, this means that the entire content of the p2 repositories specified in this way become part of the target platform.<br />
<br />
Background: In a normal (i.e. non-Tycho) Maven project, one can configure Maven repositories which can be used by Maven to resolve the project dependencies. While Maven repositories cannot be used directly (see [[#"POM dependencies consider"|below]] for an indirect approach), Tycho can use p2 repositories for resolving OSGi dependencies. The p2 repositories need to be marked with layout=p2. (The normal Maven dependency resolution ignores repositories with layout=p2.)<br />
</div><br />
<br />
=== Target files ===<br />
<br />
The PDE target definition file format (*.target) allows to select a subset of units (bundles, features, etc.) from one or more p2 repositories. In order to add the content of a target definition file (see "Content" tab of the Target Editor) to the target platform in the Tycho build, place the target file in a [[Tycho/Packaging Types#eclipse-target-definition|eclipse-target-definition]] module and configure it in the <tt>target-platform-configuration</tt> build plugin. Example:<br />
<pre><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>target-platform-configuration</artifactId><br />
<version>${tycho-version}</version><br />
<configuration><br />
<target><br />
<artifact><br />
<groupId>org.example</groupId><br />
<artifactId>target-definition</artifactId><br />
<version>1.0.0-SNAPSHOT</version><br />
</artifact><br />
</target><br />
</configuration><br />
</plugin><br />
</pre><br />
<br />
Since Tycho 0.17.0, it is also possible to configure multiple target files by specifying more than one <tt>&lt;artifact&gt;</tt> reference. Tycho interprets these target files independently and in the same way as in Eclipse: Each of the configured target files need to resolve successfully when opened in the Eclipse Target Editor. Note that the use of this Tycho feature is limited because the Eclipse PDE currently does ''not'' support activating more than one target file at once (see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=392652 bug 392652]).<br />
<br />
<p>'''Note:''' Tycho's interpretation of the target definition file format differs from the PDE in the following aspects:<br />
* The selection on the Content tab of the Target Editor is ignored. [[#Filtering|See below]] for an alternative way to remove individual bundles from the target platform.<br />
* The option "Include source if available" is considered only if <tt>target-platform-configuration</tt> parameter <tt>targetDefinitionIncludeSource</tt> is set to <tt>honor</tt> (default value). If <tt>targetDefinitionIncludeSource</tt> is set to <tt>force</tt> then available sources are always included and if set to <tt>ignore</tt> then available sources are always ignored.<br />
</p><br />
<br />
<p>'''Related Information'''<br />
* [http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Ftarget_shared%2Flocation_edit_site_wizard.htm Target editor documentation]; section on [http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Ftarget_shared%2Flocation_edit_site_wizard.htm "Software Site" locations]<br />
</p><br />
<br />
<div id="POM_Dependencies"><br />
<br />
=== Extra requirements ===<br />
<br />
<source lang="xml"><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>target-platform-configuration</artifactId><br />
<version>${tycho-version}</version><br />
<configuration><br />
<dependency-resolution><br />
<extraRequirements><br />
<requirement><br />
<type>eclipse-feature</type><br />
<id>example.project.feature</id><br />
<versionRange>0.0.0</versionRange><br />
</requirement><br />
</extraRequirements><br />
</dependency-resolution><br />
</configuration><br />
</plugin><br />
</source><br />
<br />
=== "POM dependencies consider" ===<br />
<br />
OSGi bundles from Maven repositories can be added to the target platform in the following way:<br />
# Specify a dependency to the OSGi bundle artifact in the POM's <tt>&lt;dependencies&gt;</tt> section.<br />
# Set the configuration parameter <tt>pomDependencies</tt>=<tt>consider</tt> on the <tt>target-platform-configuration</tt> plugin<br />
<br />
This configuration has the following effect:<br />
* First, Maven resolves the GAV dependencies according to the normal Maven rules. This results in a list of artifacts consisting of the specified artifacts and their transitive Maven dependencies.<br />
* Tycho then checks each of these artifacts, and ''if the artifact is an OSGi bundle'', it is added to the target platform. Other artifacts are ignored. OSGi bundles which become part of the target platform in this way are then available to resolve the project's OSGi dependencies.<br />
<br />
For an example, see the POM of this [http://git.eclipse.org/c/tycho/org.eclipse.tycho-demo.git/tree/itp02/build02 demo project].<br />
<br />
'''Note''': Tycho always attempts to resolve transitive dependencies, so if you need a POM dependency in the target platform of one module, you will also need it in all downstream modules. Therefore the POM dependencies (and the <tt>pomDependencies</tt>=<tt>consider</tt> configuration) typically need to be added in the parent POM.<br />
</div><br />
<br />
== Effective content of the target platform ==<br />
<br />
In case multiple target platform configuration approaches are combined, the target platform contains the union of the content defined through each approach.<br />
<br />
Apart from the explicitly configured content, the target platform also contains the following artifacts:<br />
* Other artifacts from the same [[Tycho/Glossary#Reactor|reactor]]<br />
* Locally built artifacts in the local Maven repository<br />
<br />
Finally, it is possible to remove artifacts again from the target platform through a filtering syntax.<br />
<br />
=== Locally built artifacts ===<br />
<br />
Just like in a normal Maven build, a Tycho build can use artifacts that have been built locally and installed (e.g. with <tt>mvn clean install</tt>) into the local Maven repository. In terms of the target platform, this means that these artifacts are implicitly added to the target platform. This is for example useful if you want to rebuild a part of a Tycho reactor, or if you want to build against a locally built, newer version of an upstream project.<br />
<br />
There are the following options to disable this feature:<br />
* Setting the CLI option <tt>-Dtycho.localArtifacts=ignore</tt> excludes locally built artifacts in one build. (<tt>tycho.localArtifacts=ignore</tt> may also be configured in the <tt>settings.xml</tt>; in this case, the default behaviour can be temporarily re-enabled with the CLI option <tt>-Dtycho.localArtifacts=default</tt>. Since Tycho 0.16.0.)<br />
* Deleting <tt>~/.m2/repository/.meta/p2-local-metadata.properties</tt> resets Tycho's list of locally build artifacts, and therefore these artifacts will not be added to target platforms (unless, of course, the artifacts are installed again).<br />
<br />
=== Filtering ===<br />
<br />
With target platform filters you can selectively remove content from the target platform. This for example allows to restrict the version of a bundle, or to select one particular provider for a package. Filtering is done as last step in the target platform computation, so the filters apply to all sources listed above.<br />
<br />
The filters are specified in the <tt>target-platform-configuration</tt> build plugin:<br />
<pre><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>target-platform-configuration</artifactId><br />
<version>${tycho-version}</version><br />
<configuration><br />
<filters><br />
<br />
<!-- example 1: restrict version of a bundle --><br />
<filter><br />
<type>eclipse-plugin</type><br />
<id>org.eclipse.osgi</id><br />
<restrictTo><br />
<versionRange>[3.6,3.7)</versionRange> <!-- alternative: <version> for selecting exactly one versions --><br />
</restrictTo><br />
</filter><br />
<br />
<!-- example 2: remove all providers of the package javax.persistence except the bundle javax.persistence --><br />
<filter><br />
<type>java-package</type><br />
<id>javax.persistence</id><br />
<restrictTo><br />
<type>eclipse-plugin</type><br />
<id>javax.persistence</id><br />
</restrictTo><br />
</filter><br />
<br />
<!-- example 3: work around Equinox bug 348045 --><br />
<filter><br />
<type>p2-installable-unit</type><br />
<id>org.eclipse.equinox.servletbridge.extensionbundle</id><br />
<removeAll /><br />
</filter><br />
</filters><br />
</configuration><br />
</plugin><br />
</pre><br />
<br />
'''Notes''':<br />
* The filters will only remove content from the target platform; they will not add new content. If you specify a restriction that is not fulfilled by any of the units from the target platform sources, all units that the filter applies to (i.e. units that match the <tt>filter.type</tt>, <tt>filter.id</tt>, and <tt>filter.version/versionRange</tt> criteria) will be removed from the target platform.<br />
* Package provider restrictions work by removing all other bundles exporting the package. This means that these other bundles (and the packages only exported by them) won't be available in your build.<br />
<br />
== Dependency resolution troubleshooting ==<br />
<br />
TODO <br />
<br />
Run mvn with the flags <tt>-Dtycho.debug.resolver=true</tt> and <tt>-X</tt> to see debug output.<br />
<br />
This will debug<br />
* Properties<br />
* Available IUs<br />
* JRE IUs<br />
* Root IUs<br />
<br />
=== Listing IUs available ===<br />
<br />
To list all the available IUs in an Eclipse repository (e.g. indigo), run:<br />
<br />
<pre><br />
$ java -jar plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar -debug -consolelog -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/releases/indigo/ -list<br />
</pre><br />
<br />
Command running with Luna and list Luna Repository<br />
<pre><br />
$ java -jar plugins/org.eclipse.equinox.launcher_1.3.0.v20140415-2008.jar -debug -consolelog -application org.eclipse.equinox.p2.director -repository http://download.eclipse.org/releases/luna/ -list<br />
</pre><br />
<br />
* Java is used (instead of the eclipse binary) so that the console output appears in the shell window instead of a spawned window<br />
* Make sure your shell is inside the Eclipse root directory<br />
* You will need to replace that version number for <tt>org.eclipse.equinox.launcher</tt> with the one found inside your Eclipse installation.<br />
* You will need to replace the Eclipse repository with the one you want a list of.<br />
<br />
This can be used to double check availability of bundle versions, and compare with what Nexus thinks is available with the source Eclipse repository.<br />
<br />
=== Browsing a p2 repository ===<br />
<br />
* In Eclipse, open the "Repository Explorer" view. If it is not available, then please install Oomph first: https://projects.eclipse.org/projects/tools.oomph/downloads<br />
* There is also a graphical p2 browser (java webstart app) available on [https://github.com/ifedorenko/p2-browser github].<br />
Just follow the instructions in the README to start it.<br />
<br />
[[Category:Tycho|Target Platform]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.7&diff=438434EGit/New and Noteworthy/5.72020-03-01T09:55:38Z<p>Michael.keppler.gmx.de: fix typo</p>
<hr />
<div>= EGit =<br />
<br />
== Repository Groups ==<br />
<br />
When a repository group is renamed in the Repositories view, a border is drawn around the editor inside the tree for better visual identification of the rename operation:<br />
<br />
[[File:Repo Group Rename.png|alt="Screenshot showing the inline renaming of repository groups in EGit 5.7.0."]]<br />
<br />
Some commands that can work on multiple repositories have been enabled on repository groups. The context menu on a repository group now also has the ''Pull'' and ''Switch Repositories To'' commands.<br />
<br />
[[File:Repo Group Multi Operations.png|alt="Screenshot of the Git Repositories view showing multi-operations enabled on repository groups in EGit 5.7.0."]]<br />
<br />
''Pull'' pulls all repositories contained in the group. ''Switch Repositories To'' allows the user to do a branch switch in all repositories, provided there is a local branch with a name common between them all. Both commands were already available if multiple repositories were selected; newly they are also active when repository ''groups'' are selected.<br />
<br />
''Switch Repositories To&rarr;New Branch...'' creates a new local branch at the current HEAD in all the selected repositories.<br />
<br />
== Comparing Commits ==<br />
<br />
=== Unified Diffs ===<br />
<br />
There is a new command ''Show Unified Diff'' available when two commits or branches or tags from the same repository are selected.<br />
<br />
[[File:Show Unified Diff.png|alt="Screenshot showing the 'Show Unified Diff' command in the Git History view in Egit 5.7.0."]]<br />
<br />
The command opens a diff viewer in the editor area of Eclipse showing the unified diff with the older commit as base. This diff viewer already existed in the Commit Viewer, "Diff" tab, where it showed the unified diff of the commit against its parent. This viewer is now available stand-alone, and can show the diff between any two commits.<br />
<br />
This is a read-only editor; many editor commands such as ''Find...'' are enabled. ''Save'' is disabled, but ''Save As...'' is available.<br />
<br />
=== Comparing Branches and Tags in the Git Repositories view ===<br />
<br />
It is now possible to compare two branches or tags in the Repositories View via the commands formerly available only in the History view: "Compare with Each Other", "Compare in Tree", and the new "Show Unified Diff".<br />
<br />
=== Searching for Commits in the Commit Selection Dialog ===<br />
<br />
The commit selection dialog openend from the ''Compare With&rarr;Commit...'' command now allows the user to search in the commit list using the same UI as in the Git History view.<br />
<br />
[[File:Find Commit.png|alt="Screenshot of the commit selection dialog showing the new 'find' toolbar in EGit 5.7.0."]]<br />
<br />
== API ==<br />
<br />
The <code>org.eclipse.egit.ui</code> bundle has a new public API: it provides a public <tt>[https://help.eclipse.org/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fcore%2Fruntime%2FIAdapterFactory.html IAdapterFactory]</tt> that can be used to define an input for the Git History page. This is useful for Eclipse bundles that have their own objects that correspond to some Git repository, commit, or branch and that want to make the Git History page show that repository or commit when such an object is selected. To use it, include an [https://help.eclipse.org/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_core_runtime_adapters.html adapter definition] in your bundle's <code>plugin.xml</code> as follows:<br />
<pre><br />
<extension point="org.eclipse.core.runtime.adapters"><br />
<factory<br />
adaptableType="org.example.myproduct.gitobjects.MyGitObject"<br />
class="org.eclipse.egit.ui.history.GitHistoryAdapterFactory"><br />
<adapter type="org.eclipse.team.ui.history.IHistoryPageSource" /><br />
</factory><br />
</extension><br />
</pre><br />
The <tt>adaptableType</tt> objects (<tt>MyGitObject</tt> in the example) also need to be adaptable to <code>org.eclipse.jgit.lib.Repository</code>, and optionally to <code>org.eclipse.jgit.revwalk.RevCommit</code>. The Git History view, if set to follow the selection in other views, will then show the history of that repository whenever the current selection is a <tt>MyGitObject</tt>.<br />
<br />
:'''Deprecation Warning''': EGit UI already included an ''internal'' adapter factory <tt>org.eclipse.egit.ui.internal.factories.GitAdapterFactory</tt> for this. External bundles using that internal factory should switch to using the new public API <code>org.eclipse.egit.ui.history.GitHistoryAdapterFactory</code>. Adaptation to <code>IHistoryPageSource</code> ''will be removed from the internal factory'' in the next EGit release.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.7 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.7.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following X developers worked on this release:<br />
<br />
<TBD: list of contributors, number><br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.7|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=FAQ_How_do_I_upgrade_Eclipse_IDE%3F&diff=437148FAQ How do I upgrade Eclipse IDE?2019-12-15T15:18:20Z<p>Michael.keppler.gmx.de: use https</p>
<hr />
<div>== Upgrading existing Eclipse IDE and Installed Features to newer release ==<br />
<br />
To upgrade Eclipse IDE to the next major release<br />
# You first need to [https://help.eclipse.org/2019-09/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-128.htm add the new release's repository] as follows:<br />
## Window > Preferences > Install/Update > Available Software Sites<br />
## Click 'Add'<br />
## Enter the URL of the new repository (for example, https://download.eclipse.org/releases/2019-09/ ). <!-- TODO update when a new version is released --><br />
<!-- Important: Followup https://bugs.eclipse.org/bugs/show_bug.cgi?id=483786 about URL pattern --><br />
## Click 'Ok'<br />
# [https://help.eclipse.org/2019-06/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-120.htm Help > Check for Updates]<br />
# If updates are found, proceed through the install wizard and restart the IDE when prompted. Otherwise, read carefully the error message to find out which component is conflicting and establish your resolution strategy.<br />
# Note that the start splash screen may be cached and will not necessarily be updated to the latest version after the IDE is restarted. Performing a full relaunch should display the new version number.<br />
<br />
== Always enable major upgrades ==<br />
<br />
To always enable major upgrades of your IDE once and for all:<br />
# Open the ''Available Software Sites'' preference page<br />
# Enable the ''Latest Eclipse release https://download.eclipse.org/releases/latest'' repository by ticking the checkbox.<br />
# Apply and Close<br />
# Check for updates<br />
<br />
The similar workflow can be used to hide and disable automatic proposal of major upgrades.<br />
<br />
== Beta-testing milestones and release candidates ==<br />
<br />
The same process as above can be used to enable update to milestones or release candidates of the Eclipse IDE (which have already been partially tested before being published, but might still contain unknown issues for you to [https://bugs.eclipse.org/bugs/enter_bug.cgi report to Bugzilla]). The only difference is that you should add the 2 following URLs as [https://help.eclipse.org/2018-12/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-128.htm Available sites] before running [https://help.eclipse.org/2018-12/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-120.htm Check for updates] in order to let Eclipse IDE locate the milestones/release-candidates:<br />
* Assuming next release name is ''2019-09''<br />
** https://download.eclipse.org/staging/2019-09/<br />
** https://download.eclipse.org/releases/2019-09/ (this is the same URL that will be used for release)<br />
<!-- Important: keep up to date with repo layout changes: https://bugs.eclipse.org/bugs/show_bug.cgi?id=489758 and similar --><br />
<br />
== Fresh install ==<br />
<br />
If you prefer not performing an update (for example because some 3rd-party content is not ready for the current release of Eclipse IDE and the update reports conflicts), you can still download a fresh install of the Eclipse IDE and install it in another location on your filesystem, and use it together with the previous version.<br />
<br />
To do so, download a new build from the Eclipse download website (https://www.eclipse.org/downloads/eclipse-packages/) and run the installer or unzip the archive in a new directory. We strongly recommend against installing/unzipping over your existing version of Eclipse IDE as it may corrupt your installation.<br />
<br />
When you start a new version of Eclipse IDE, you can use the same existing workspace folder that you were using with the older version. The workspace will be migrated to a newer version and the Eclipse IDE will reuse all configurations. The workspace is forward compatible, but might not be backward compatible.<br />
<br />
== Windows specifics ==<br />
<br />
If Eclipse IDE is installed in a restricted directory, upgrades may require administrator privileges to succeed and may fail with error messages claiming "Only one of the following can be installed:" otherwise. Start Eclipse with "Run as administrator...".<br />
<br />
== Older versions (deprecated) ==<br />
<br />
=== Upgrading from previous versions to Neon (4.6) is NOT supported ===<br />
<br />
'''Upgrading from Mars (4.5) and older Eclipse IDE package to Neon (4.6) is NOT supported''' ''NOTE: Due to structural changes you cannot update from a Mars (or prior) all-in-one package to a Neon version. If interested in the technical details, see {{bug|332989}} and {{bug|490515}}. So to use Eclipse Neon IDE, you have to go for a [[#Fresh Install]]. From Neon to Oxygen and later, the usual upgrade process detailed above works.<br />
<br />
=== Upgrading from Ganymede (3.4) ===<br />
If you're using '''Ganymede (3.4)''': To upgrade installed software, do the following:<br />
<br />
#Help > Software Updates...<br />
#Switch to the 'Installed Software' pane<br />
#Select one or more installed items to be upgraded. If nothing is selected, it will search for updates to all installed software<br />
#Select 'Update', and proceed through the wizard if updates are found<br />
<br />
=== Upgrading from Europa (3.3) and below ===<br />
<br />
If you're using '''Europa (3.3) and below''': Run the Update Manager, using <tt>Help &gt; Software Updates &gt; Find and Install... &gt; Search for updates of the currently installed features</tt>. The Update Manager will visit the Update site(s) for all your installed features/plugins and offer updates if any exist. However, in Eclipse 3.3 or earlier, it is '''''NOT''''' possible to upgrade the Eclipse platform itself, only its features. So, you could for example upgrade the CVS feature or the PDE feature from 3.2.0 to 3.2.1, but not eclipse.exe itself.<br />
<br />
=== Upgrading Other Features ===<br />
<br />
Upgrading other features (like CDT, PDT, WTP...) can be done without the need to [https://download.eclipse.org/eclipse/downloads/ download a new platform binary], but because many projects align very closely (eg., the [https://www.eclipse.org/callisto/ Eclipse 3.2 / Callisto] or [https://www.eclipse.org/europa/ Eclipse 3.3 / Europa] release trains) you will likely need to upgrade the Eclipse platform as well. <br />
<br />
== See Also: ==<br />
<br />
* [[FAQ_How_do_I_update_Eclipse%3F]]<br />
* [[FAQ_What_is_the_Update_Manager%3F]]<br />
* [https://stackoverflow.com/questions/17337526/how-to-upgrade-eclipse-for-java-ee-developers-from-juno-to-kepler How to upgrade Eclipse for Java EE Developers from Juno to Kepler?]<br />
<br />
<br />
<br />
{{Template:FAQ_Tagline}}<br />
<br />
[[Category:FAQ]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.6&diff=434864Tycho/Release Notes/1.62019-10-21T12:29:48Z<p>Michael.keppler.gmx.de: news for performance fix</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.5|&lt; Previous Version]] | [[Tycho/Release Notes/1.7|Next Version &gt;]]</div><br />
<br />
== SNAPSHOT builds ==<br />
<br />
Tycho 1.6.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.6.0-SNAPSHOT</tt>.<br />
<br />
<source lang="xml"><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</source><br />
<br />
<!--<br />
== Staging build ==<br />
<br />
Tycho 1.6.0 is currently staged for release. To try out the release candidate, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.6.0</tt>.<br />
<br />
<source lang="xml"><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-staged</id><br />
<url>TODO</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</source><br />
--><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://ci.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
[[Category:Tycho|Release Notes/1.6]]<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.6.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.6.0-SNAPSHOT]<br />
<br />
=== Faster target platform resolution ===<br />
<br />
{{bug|551974}} Tycho needs to resolve the target platform during the initial phase of a build. This is now much faster than before, thanks to improved caching. In an example application with 800 bundles in its target platform Tycho 1.5 needs about 2 seconds per Maven module for target platform resolution, while Tycho 1.6 needs about 0.2 seconds per Maven module.<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.6]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.5&diff=434304EGit/New and Noteworthy/5.52019-09-18T20:47:14Z<p>Michael.keppler.gmx.de: add video</p>
<hr />
<div>= EGit =<br />
<br />
== Creating Lightweight Tags ==<br />
<br />
With EGit 5.5, you can create lightweight tags. Just leave the message field in the "Create Tag" dialog empty:<br />
<br />
[[File:Create Lightweight Tag.png|alt=Screenshot of the "Create Tag" dialog showing the tooltip on the "Create" button explaining this.]]<br />
<br />
A lightweight tag doesn't store any author information (who created the tag) or message, and it cannot be signed. It is really just a plain name for a commit. An annotated commit, on the other hand, additionally stores a message, and also the author of the tag.<br />
<br />
If an existing tag is selected and the "Force replace existing tag" option is checked, the dialog can also be used to move a tag (make it refer to a different commit than before), or to change an annotated tag into a lightweight tag (by clearing the message) or vice versa (by adding a message).<br />
<br />
== History View ==<br />
<br />
=== Option to Show First Parents Only ===<br />
<br />
A history graph with many merges can be very hard to read. Therefore native git log has an option --first-parent, which shows only the first parent of each merge commit. This is now also available in the EGit history view.<br />
<br />
[[File:Egit-first-parent.png|alt=History with first parent only enabled]]<br />
<br />
Notice the many merge commits in the history, which all show only one parent, instead of splitting into more and more lines.<br />
<br />
=== Shorter View Toolbar ===<br />
<br />
The toolbar of the history view has been made shorter:<br />
<br />
[[File:EGit HistoryView filter.png|alt=Screenshot of the Egit History View with the four resource filter buttons combined into one button with a drop-down menu]]<br />
<br />
Instead of four individual buttons for the resource filters there's now only one button with a drop-down menu. Clicking the button cycles through the filters; the button's icon changes depending on the chosen filter.<br />
<br />
== Renaming branches became easier ==<br />
<br />
Before EGit 5.5 you had to navigate to a branch node in the repository view, in order to rename the branch. Now you can use the F2 key for renaming a branch both on the branch node or on the repository node. No need to expand all the nodes down to the branch node anymore.<br />
<br />
== Staged files as list or tree ==<br />
<br />
EGit had an option to display the staged and unstaged files as a flat list or as a tree of folders and files since a long time already. Both can be very helpful when you want to stage only some of many changed files, either based on their name or based on their location. To make more users aware of the different presentations, the option can now be changed more easily via a dropdown menu next to the unstaged files area in the history view.<br />
<br />
[[File:EGit 5 5 Staging Presentation.png|alt=Screenshot of the EGit Staging view showing the new "Presentation" button and drop-down menu]]<br />
<br />
The button's icon changes depending on the selected mode.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.5 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.5.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following 9 developers worked on this release:<br />
<br />
Aaron S. Hawley,<br />
Florian Meyer,<br />
Lars Vogel,<br />
Marco Stornelli,<br />
Matthias Sohn,<br />
Max Hohenegger,<br />
Michael Keppler,<br />
Thomas Wolf,<br />
Tim Neumann<br />
<br />
= Video =<br />
<br />
You can see many of the changes in action in the [https://www.youtube.com/watch?v=CpAxzfkb8to Eclipse 2019-09 IDE Improvements: General and Git] video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.5|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=434196EGit/Contributor Guide2019-09-12T05:28:49Z<p>Michael.keppler.gmx.de: use https</p>
<hr />
<div>= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[https://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Automated Developer Setup =<br />
The fastest developer setup for contributing to JGit/EGit is to use the Eclipse Installer and the<br />
EGit project setup to prepare an Eclipse IDE for JGit/EGit:<br />
* download and unpack the [https://www.eclipse.org/downloads/eclipse-packages/ Eclipse Installer]<br />
* start the Eclipse Installer<br />
* select the advanced mode<br />
[[File:Oomph-01-advanced-mode.png]]<br />
* if the right most icon in the bottom toolbar of the installer rotates, there is an update available for the installer, which should be installed before continuing<br />
* if you are behind a proxy, change the proxy settings from the toolbar at the bottom<br />
[[File:Oomph -01a-proxy-settings.png]]<br />
* on the product page select "Eclipse IDE for Eclipse Committers" and click "Next"<br />
[[File:Oomph-02-proxy-product-selection.png]]<br />
* on the project page select project "EGit" and click "Next"<br />
[[File:Oomph-03-project-egit.png]]<br />
* on Variables page accept default target platform, to fine tune variables click "Show all variables", click "Next"<br />
* on the Confirmation page click "Finish"<br />
[[File:Oomph-04-installer-progress.png]]<br />
* the installer installs the chosen IDE and starts it, as soon as the installer says "Press Finish to close the dialog" you can close the installer window<br />
* the newly installed IDE will automatically clone the JGit and EGit repositories and configure the workbench for JGit/EGit development. You can observe the setup progress in the toolbar, if necessary you can reopen the setup wizard by clicking its icon in the status bar<br />
[[File:Oomph-05-eclipse-progress.png]]<br />
* when the setup finished the IDE should looks similar to this<br />
[[File:Oomph-06-ide.png]]<br />
<br />
If you want to improve the EGit project setup, check the setup file in tools\oomph\EGit.setup (in your newly cloned egit repository). You can find more information about Oomph at<br />
* https://help.eclipse.org/<br />
* https://projects.eclipse.org/projects/tools.oomph<br />
* https://wiki.eclipse.org/Eclipse_Installer<br />
* https://wiki.eclipse.org/Eclipse_Oomph_Authoring<br />
<br />
= Manual Developer Setup =<br />
== Obtaining Sources ==<br />
EGit and JGit are self hosted in Git. You can browse the repositories on the web: <br />
[https://git.eclipse.org/c/egit/ EGit], [https://git.eclipse.org/c/jgit/ JGit]<br />
<br />
The first section below describes how to clone a repository and can be skipped if you have done this before.<br />
The next section lists the repositories and their URLs.<br />
<br />
=== Cloning ===<br />
==== On the command line ====<br />
<br />
<pre style="width: 40em;"><br />
git clone <enter URL><br />
</pre><br />
<br />
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.<br />
<br />
==== Using EGit (see [https://www.eclipse.org/egit/download/ download page]) ====<br />
<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
Then, clone the repository and import the projects:<br />
<br />
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''<br />
* Selet ''URI''<br />
* Enter the URL (see next section) <br />
* Import existing projects into the workspace from the newly created working directory<br />
<br />
=== Repositories ===<br />
<br />
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed. <br />
<br />
==== EGit ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit.git<br />
<br />
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.<br />
<br />
==== JGit ====<br />
<br />
URL: https://git.eclipse.org/r/jgit/jgit.git<br />
<br />
This is the Java implementation of Git used by EGit, for working with Git repositories.<br />
<br />
==== EGit GitHub Integration ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-github.git<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
For getting the dependencies, open the file <code>org.eclipse.mylyn.github-feature/github.target</code> ([https://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''.<br />
<br />
==== EGit PDE Tools ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-pde.git<br />
<br />
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. <br />
<br />
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 Git in your workspaces.<br />
<br />
== Development IDE Configuration ==<br />
<br />
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:<br />
<br />
https://www.eclipse.org/downloads/packages/<br />
<br />
=== Tools ===<br />
<br />
To install all the necessary tools to work on EGit/JGit, there is a [https://git.eclipse.org/c/egit/egit.git/plain/tools/egit-developer-tools.p2f egit-developer-tools.p2f] file which you can use as follows:<br />
<br />
* File > Import > Install > Install Software Items from File<br />
* Browse...<br />
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''<br />
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it<br />
* All the items you don't already have should be selected automatically<br />
* Finish the wizard<br />
* Restart<br />
<br />
=== Java Requirements ===<br />
<br />
EGit and JGit have Java 8.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 4.6 (Neon)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.<br />
<br />
We are using ''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 8. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].<br />
<br />
=== Dependencies ===<br />
<br />
After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies.<br />
Set a Target Platform to fix this<br />
<br />
[[Image:EGit-Target-Platforms.png|right|EGit target platforms in org.eclipse.egit.target]]<br />
* Open the ''org.eclipse.egit.target'' project<br />
* 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)<br />
* 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)<br />
<br />
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,<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
= Running EGit from Eclipse =<br />
<br />
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:<br />
<br />
* Right click on the ''org.eclipse.egit.ui'' project<br />
* Debug As &gt; Eclipse Application<br />
<br />
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.<br />
<br />
The launch configuration can also be used in normal (non-debug) mode of course.<br />
<br />
Also see the [https://help.eclipse.org/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Flaunchers%2Feclipse_application_launcher.htm reference on eclipse application launchers].<br />
<br />
<br/><br />
<br />
= Builds =<br />
<br />
The central EGit and JGit builds run on the Jenkins build infrastructure provided by the Eclipse foundation.<br />
* [https://ci.eclipse.org/egit/ EGit Jenkins instance]<br />
* [https://ci.eclipse.org/jgit/ JGit Jenkins instance]<br />
<br />
Prerequisites for the Maven build are<br />
* [https://maven.apache.org/download.html at least Maven 3.5.2]<br />
* see [https://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration<br />
* if you want to learn how Maven works start reading [https://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven or Bazel<br />
* use Java 8 to run the JGit build<br />
* JGit packaging projects (Eclipse features and p2 repository) are built using Maven and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build ==<br />
* Due to a [https://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts 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.<br />
* The local maven builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* To run the build behind a firewall follow https://maven.apache.org/guides/mini/guide-proxies.html <br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit-github<br />
<br />
[~/src/egit-github] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository<br />
<br />
in the same way you can configure a custom path for the build of egit-github to the egit p2 repository<br />
<br />
[~/src/egit-github] $ mvn clean install -Degit-site=file:/path/to/egit/org.eclipse.egit.repository/target/repository<br />
<br />
The Jenkins build uses (for SNAPSHOT builds):<br />
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/<br />
org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/<br />
<br />
If you wan to build EGit for the specific Photon (4.8) platform, consider using the <code>egit-4.8</code> target platform:<br />
[~/src/egit] $ mvn -Dtarget-platform=egit-4.8 clean install<br />
<br />
For EGit version 4.10, <code>egit-4.5</code> (Mars, Eclipse 4.5), <code>egit-4.6</code> (Neon, Eclipse 4.6), <code>egit-4.7</code> (Oxygen, Eclipse 4.7), and <code>egit-4.8</code> (Photon, Eclipse 4.8) are available. In addition <code>egit-4.8-staging</code> refers to the Photon staging repository.<br />
<br />
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.7. If you skip setting the system property <code>target-platform</code> the target platform for Eclipse 4.7 will be used.<br />
<br />
==JGit Bazel Build==<br />
Since Gerrit is built using [https://www.bazel.io/ Bazel] a Bazel build was also implemented for JGit.<br />
This simplifies working on Gerrit features which also require changes in JGit.<br />
* [https://www.bazel.io/versions/master/docs/install.html Install Bazel]<br />
* To build all libraries run<br />
bazel build :all<br />
* The following test labels are supported: api, attributes, dfs, diff, http, lfs, lfs-server, nls, notes, pack, patch, pgm, reftree, revplot, revwalk, storage, submodule, symlinks, transport, treewalk, util<br />
* To run all tests execute<br />
bazel test //...<br />
* To run specific tests, using labels:<br />
bazel test --test_tag_filters=api,dfs,revplot,treewalk //...<br />
* to rerun all tests ignoring cached test results execute<br />
bazel test //... --cache_test_results=NO<br />
* to set number of concurrent test runs<br />
bazel test //... --jobs=4<br />
* to debug a test run<br />
bazel test --test_output=streamed --test_filter=<fully qualified test method> <test target><br />
e.g.<br />
bazel test --test_output=streamed --test_filter=org.eclipse.jgit.api.GitConstructionTest.testClose //org.eclipse.jgit.test:org_eclipse_jgit_api_GitConstructionTest<br />
* to configure loggers for test runs edit org.eclipse.jgit.test/tst-rsrc/simplelogger.properties, see the [https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html slf4j SimpleLogger documentation]<br />
* to run tests repeatedly use<br />
bazel test --runs_per_test=3 <test target><br />
* since 5.4.0 builds run with [https://github.com/google/error-prone the errorprone static analyzer] by default. If you want to enable it for older JGit versions execute<br />
bazel build --java_toolchain //tools:error_prone_warnings_toolchain :all<br />
<br />
<br />
Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://ci.eclipse.org/jgit/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://ci.eclipse.org/jgit/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://ci.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]<br />
* [https://ci.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Checking for JGit API Changes using API Baseline ==<br />
<br />
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:<br />
* 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.9.1</code>, find the p2 repository URLs [https://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<br />
* in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.9.1) and point it to the local copy of the corresponding EGit p2 repository.<br />
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems<br />
* see the [https://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.<br />
<br />
== Signing and Publishing ==<br />
EGit and JGit builds running on the JGit/EGit Jenkins instances are automatically signed <br />
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder<br />
<pre><br />
master branch: /home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
latest stable branch: /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly<br />
</pre><br />
<br />
* 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://ci.eclipse.org/egit/<br />
<br />
== Contribution to Release Train ==<br />
<br />
The release train contribution for JGit and EGit is maintained in the git repository <br />
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre><br />
in the file<br />
<pre>egit.aggrcon</pre><br />
<br />
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 />
<br/><br />
<br />
= Documentation =<br />
== JGit ==<br />
The JGit project generates a project report and javadocs using a Maven site. This Maven site is deployed to https://download.eclipse.org/jgit/site/${project.version}.<br />
E.g. https://download.eclipse.org/jgit/site/4.4.1.201607150455-r/<br />
<br />
Generating the site:<br />
'''$ mvn site:site'''<br />
<br />
Staging the site locally under ./target/staging:<br />
'''$ mvn site:stage'''<br />
<br />
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:<br />
'''$ mvn site:deploy'''<br />
The site is deployed under https://download.eclipse.org/jgit/site/${project.version}<br />
<br />
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:<br />
<server><br />
<id>jgit.website</id><br />
<username>username</username><br />
<privateKey>${user.home}/.ssh/id_rsa</privateKey><br />
<password>{<encrypted passphrase>}</password><br />
<filePermissions>664</filePermission><br />
<directoryPermissions>775</directoryPermissions><br />
<configuration></configuration><br />
</server><br />
<br />
Password encryption for Maven is described in https://maven.apache.org/guides/mini/guide-encryption.html<br />
<br />
To deploy the site from JGit HIPP (Hudson) at https://hudson.eclipse.org/jgit/ enable the Maven profile '''build-server''' and add the Maven goals '''site:site site:deploy'''.<br />
<br />
If you uploaded the site for a new release update the index<br />
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html<br />
to refer to the new release's site.<br />
<br />
== EGit ==<br />
The EGit project sources its documentation from the wiki and generates Eclipse help content from it (under the covers, we are using [https://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 [https://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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.<br />
<br />
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].<br />
<br />
Alternatively, install "Jetty 9.4.20.v20190813" from https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.20.v20190813/<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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''.<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":<br />
* https://download.eclipse.org/technology/swtbot/snapshots/<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== During Maven Build ===<br />
<br />
The tests are executed in the integration-test phase of the [https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html default Maven lifecycle].<br />
<br />
If you want to skip execution of UI tests (only execute core tests):<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
If you want to skip all tests:<br />
<br />
mvn clean install -Dmaven.test.skip=true<br />
<br />
== Auxilary testing tools ==<br />
<br />
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 [https://www.eclemma.org/ EclEmma] can easily visualize what part of the code is being executed.<br />
<br />
= Bugs =<br />
<br />
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":<br />
<br />
[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]<br />
<br />
[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]<br />
<br />
== Links ==<br />
=== Filing Bugs ===<br />
==== How to file bugs ==== <br />
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]] <br />
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]<br />
*[https://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham<br />
<br />
==== File a bug ====<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
==== File a bug for a vulnerability ====<br />
If you discovered a vulnerability you want to report <br />
* create a bug in Bugzilla here https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit<br />
* click "Show Advanced Fields" <br />
* and check the option "Committer-only group for handling security advisories in a closed fashion."<br />
* describe the vulnerability<br />
this will ensure that the discussion on the vulnerability is kept private between the reporter and the committer group<br />
until the project prepared a release fixing the vulnerability<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends (bugs and enhancements)<br />
!EGit <br />
!JGit<br />
|-<br />
|Open by component (date range editable)<br />
|[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] <br />
|[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]<br />
|-<br />
|Open by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|-<br />
|Assigned <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned] <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|Open and closed by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed target milestones</span> <br />
| [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]<br />
| [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]<br />
|-<br />
| Open bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open enhancements<br />
| [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]<br />
| [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]<br />
|-<br />
| Bugs with votes<br />
| [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]<br />
| [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]<br />
|-<br />
|Assigned bugs and enhancements <br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit bugs<br />
| 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]<br />
|-<br />
| New bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><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''.<br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
== Spam Bugs ==<br />
If you come across spam bugs you can request webmaster to delete them by marking them as duplicate of bug 442999.<br />
<br />
Also see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=502814 bug 502814]<br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.<br />
<br />
'''egit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''<br />
* 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 />
'''jgit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''<br />
* 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 />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
== Using Gerrit at Eclipse ==<br />
<br />
EGit and JGit projects are using [https://www.gerritcodereview.com/ Gerrit Code Review] for Git based patch submission and review. <br />
<br />
Parts of this chapter are also available in the [https://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].<br />
<br />
Both projects can accept contributions ''only'' via Gerrit. Please do not send patches by e-mail. Although both projects are mirrored to Github, EGit and JGit also cannot accept Github pull requests.<br />
<br />
=== User Account ===<br />
*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.<br />
<br />
=== Legal Paperwork ===<br />
<br />
Before your first contribution can be accepted, you need to electronically sign the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement] (ECA). The ECA is good for three years. Find more information in the [https://www.eclipse.org/legal/ecafaq.php ECA FAQ].<br />
<br />
Minimally, all Git commits you contribute must have the following:<br />
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;<br />
* Your credentials (email address) captured in the "Author" field; and<br />
* A "Signed-off-by" entry with matching credentials in the comment.<br />
* The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the [https://www.eclipse.org/legal/DCO.php Developer Certificate of Origin].<br />
<br />
In addition ensure<br />
* that the contributed code is licensed under the project license (EPL 2.0 for EGit and EDL 1.0 for JGit). This is done by putting a [https://www.eclipse.org/projects/handbook/#ip-copyright-headers copyright and license header] into every new java file. See other existing project source files for the correct content.<br />
<br />
With a valid ECA 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.<br />
<br />
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:<br />
* If it's committed: <tt>git log --shortstat</tt><br />
* If not committed: <tt>git diff --stat</tt><br />
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.<br />
<br />
Find more details about how to contribute in [https://wiki.eclipse.org/Development_Resources/Contributing_via_Git Contributing via Git (for contributors)] and [https://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions Handling Git Contributions (for committers)].<br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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 [https://help.github.com/working-with-key-passphrases use a passphrase].<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [https://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*The [https://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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[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 [https://wiki.eclipse.org/EGit/User_Guide#Gerrit_Configuration configure pushing to the code review queue].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** 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.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from https://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** 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.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
== Granularity of Changes ==<br />
<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
<br />
=== Branches ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedence.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
=== Braces for one-line statements ===<br />
<br />
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.:<br />
<br />
if (condition)<br />
doSomething();<br />
<br />
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:<br />
<br />
if (condition) {<br />
doSomething();<br />
}<br />
<br />
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}}.<br />
<br />
=== Removing trailing whitespace ===<br />
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}}.<br />
<br />
As a workaround, use the following sequence of commands in the Java editor to trick the save action:<br />
* remove the offending trailing whitespace<br />
* the save action re-adds the trailing whitespace<br />
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again<br />
<br />
Another workaround is to use [https://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.<br />
<br />
=== Use of the "final" modifier ===<br />
<br />
New code uses the "final" modifier in the following circumstances[https://gerrit-review.googlesource.com/c/gerrit/+/61701/].<br />
<br />
Always:<br />
* final fields: marking fields as final forces them to be initialized in the constructor or at declaration<br />
* final static fields: clearly communicates the intent<br />
* where necessary to use final variables in inner anonymous classes<br />
<br />
Optional:<br />
* final classes: use when appropriate, e.g. API restriction<br />
* final methods: similar to final classes<br />
<br />
Never:<br />
* local variables: it clutters the code, and makes the code less readable. When copying old code to new location, finals should be removed<br />
* method parameters: similar to local variables<br />
<br />
== Commit message guidelines ==<br />
<br />
*The commit message header should fit on one line. A blank line separates it from the body of the message.<br />
*The first line should be a clear and concise description about the change. It is recommended to start with the modified subsystem, followed by a colon and a description starting with capital letter and without period at the end. For example: <code>UploadPack: Use reachability checker to validate non-advertised wants</code><br />
*In case of release engineering tasks without bugzilla entries the commit message header may look like "[findbugs] Fix warning XYZ for String constructor". The prefix in brackets is an indication why this comes without a corresponding bug. <br />
*Enter a newline before providing a more detailed description about the change.<br />
*Format the commit message to have newline characters after every 60-70 characters. <br />
*Find more reasoning about commit message formatting in [https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html "A Note About Git Commit Messages"]<br />
*''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.<br />
**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. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.<br />
**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<br />
**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''.<br />
**A "Signed-off-by" can be added at the end of the commit message (see example below). Note: At the moment this footer is not required for committers, but for non-committer contributors. It may be used to list all who modified (amended, rebased, cherry-picked) this change.<br />
<br />
<br />
<pre>CommitDialog: Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
CQ: 6031<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
If you use Mylyn to fetch a bug from bugzilla, and then activate the task, the commit message will automatically be formatted exactly like requested above.<br />
<br />
== License Header ==<br />
<br />
JGit is licensed under the [https://www.eclipse.org/org/documents/edl-v10.php Eclipse Distribution License] which is a form of the [https://opensource.org/licenses/BSD-3-Clause New BSD License].<br />
Use of this license by an Eclipse project requires unanimous approval by the Board of Directors of the Eclipse Foundation<br />
which was approved in a [https://www.eclipse.org/org/foundation/boardminutes/2009_09_16_Minutes.php meeting of the board in Sep 2009].<br />
<br />
The license and copyright header to be used for JGit is<br />
<br />
/*<br />
* Copyright (c) YEAR CONTRIBUTOR[ and others]<br />
* <br />
* This program and the accompanying materials are made available under the<br />
* terms of the Eclipse Distribution License v. 1.0 which is available at<br />
* https://www.eclipse.org/org/documents/edl-v10.php.<br />
* <br />
* SPDX-License-Identifier: BSD-3-Clause<br />
*/<br />
<br />
See https://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.<br />
<br />
== Copyright ==<br />
<br />
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.<br />
<br />
When there is only one copyright present (from a person or a company), like this:<br />
<br />
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org><br />
</pre><br />
<br />
Change it like this (notice the updated year):<br />
<br />
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.<br />
</pre><br />
<br />
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.<br />
<br />
When there are multiple copyright entries there, add yours as a separate line. So, given this:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
</pre><br />
<br />
Add another line:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
Copyright (C) YEAR Your Name <you@example.org><br />
</pre><br />
<br />
For new files, copy one of the existing headers and start the copyright section with your name.<br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
* Add automated tests for enhancements and bug fixes to ensure functional correctness and avoid regressions<br />
* Run all existing tests. It does not take very long.<br />
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 8 and Eclipse 4.4. You cannot use API's that are newer.<br />
<br />
== Sending patches by mail ==<br />
<br />
EGit and JGit can accept patches only via Gerrit as per [[#Contributing_Patches]].<br />
<br />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
You can alternatively [https://git.eclipse.org/r/tools/hooks/commit-msg download the file]. The [https://gerrit-review.googlesource.com/Documentation/cmd-hook-commit-msg.html hook] helps append a Change-Id to your commit message.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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, [https://git.eclipse.org/r/2 https://git.eclipse.org/r/2] shows the 'download' section for each patchset. In this case, it looks like: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
We have build jobs '''jgit.gerrit''' on https://hudson.eclipse.org/jgit/, and '''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.<br />
<br />
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.<br />
Committers can manually trigger these jobs in the following way:<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
If you are not a committer and need to retrigger a build ask for that on the mailing list.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
The IP review category indicates whether or not the change has been properly logged under the [https://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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=434195EGit/Contributor Guide2019-09-12T05:22:46Z<p>Michael.keppler.gmx.de: fix typo</p>
<hr />
<div>= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[https://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Automated Developer Setup =<br />
The fastest developer setup for contributing to JGit/EGit is to use the Eclipse Installer and the<br />
EGit project setup to prepare an Eclipse IDE for JGit/EGit:<br />
* download and unpack the [https://www.eclipse.org/downloads/eclipse-packages/ Eclipse Installer]<br />
* start the Eclipse Installer<br />
* select the advanced mode<br />
[[File:Oomph-01-advanced-mode.png]]<br />
* if the right most icon in the bottom toolbar of the installer rotates, there is an update available for the installer, which should be installed before continuing<br />
* if you are behind a proxy, change the proxy settings from the toolbar at the bottom<br />
[[File:Oomph -01a-proxy-settings.png]]<br />
* on the product page select "Eclipse IDE for Eclipse Committers" and click "Next"<br />
[[File:Oomph-02-proxy-product-selection.png]]<br />
* on the project page select project "EGit" and click "Next"<br />
[[File:Oomph-03-project-egit.png]]<br />
* on Variables page accept default target platform, to fine tune variables click "Show all variables", click "Next"<br />
* on the Confirmation page click "Finish"<br />
[[File:Oomph-04-installer-progress.png]]<br />
* the installer installs the chosen IDE and starts it, as soon as the installer says "Press Finish to close the dialog" you can close the installer window<br />
* the newly installed IDE will automatically clone the JGit and EGit repositories and configure the workbench for JGit/EGit development. You can observe the setup progress in the toolbar, if necessary you can reopen the setup wizard by clicking its icon in the status bar<br />
[[File:Oomph-05-eclipse-progress.png]]<br />
* when the setup finished the IDE should looks similar to this<br />
[[File:Oomph-06-ide.png]]<br />
<br />
If you want to improve the EGit project setup, check the setup file in tools\oomph\EGit.setup (in your newly cloned egit repository). You can find more information about Oomph at<br />
* https://help.eclipse.org/<br />
* https://projects.eclipse.org/projects/tools.oomph<br />
* https://wiki.eclipse.org/Eclipse_Installer<br />
* https://wiki.eclipse.org/Eclipse_Oomph_Authoring<br />
<br />
= Manual Developer Setup =<br />
== Obtaining Sources ==<br />
EGit and JGit are self hosted in Git. You can browse the repositories on the web: <br />
[https://git.eclipse.org/c/egit/ EGit], [https://git.eclipse.org/c/jgit/ JGit]<br />
<br />
The first section below describes how to clone a repository and can be skipped if you have done this before.<br />
The next section lists the repositories and their URLs.<br />
<br />
=== Cloning ===<br />
==== On the command line ====<br />
<br />
<pre style="width: 40em;"><br />
git clone <enter URL><br />
</pre><br />
<br />
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.<br />
<br />
==== Using EGit (see [https://www.eclipse.org/egit/download/ download page]) ====<br />
<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
Then, clone the repository and import the projects:<br />
<br />
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''<br />
* Selet ''URI''<br />
* Enter the URL (see next section) <br />
* Import existing projects into the workspace from the newly created working directory<br />
<br />
=== Repositories ===<br />
<br />
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed. <br />
<br />
==== EGit ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit.git<br />
<br />
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.<br />
<br />
==== JGit ====<br />
<br />
URL: https://git.eclipse.org/r/jgit/jgit.git<br />
<br />
This is the Java implementation of Git used by EGit, for working with Git repositories.<br />
<br />
==== EGit GitHub Integration ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-github.git<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
For getting the dependencies, open the file <code>org.eclipse.mylyn.github-feature/github.target</code> ([https://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''.<br />
<br />
==== EGit PDE Tools ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-pde.git<br />
<br />
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. <br />
<br />
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 Git in your workspaces.<br />
<br />
== Development IDE Configuration ==<br />
<br />
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:<br />
<br />
https://www.eclipse.org/downloads/packages/<br />
<br />
=== Tools ===<br />
<br />
To install all the necessary tools to work on EGit/JGit, there is a [https://git.eclipse.org/c/egit/egit.git/plain/tools/egit-developer-tools.p2f egit-developer-tools.p2f] file which you can use as follows:<br />
<br />
* File > Import > Install > Install Software Items from File<br />
* Browse...<br />
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''<br />
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it<br />
* All the items you don't already have should be selected automatically<br />
* Finish the wizard<br />
* Restart<br />
<br />
=== Java Requirements ===<br />
<br />
EGit and JGit have Java 8.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 4.6 (Neon)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.<br />
<br />
We are using ''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 8. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].<br />
<br />
=== Dependencies ===<br />
<br />
After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies.<br />
Set a Target Platform to fix this<br />
<br />
[[Image:EGit-Target-Platforms.png|right|EGit target platforms in org.eclipse.egit.target]]<br />
* Open the ''org.eclipse.egit.target'' project<br />
* 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)<br />
* 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)<br />
<br />
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,<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
= Running EGit from Eclipse =<br />
<br />
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:<br />
<br />
* Right click on the ''org.eclipse.egit.ui'' project<br />
* Debug As &gt; Eclipse Application<br />
<br />
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.<br />
<br />
The launch configuration can also be used in normal (non-debug) mode of course.<br />
<br />
Also see the [https://help.eclipse.org/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Flaunchers%2Feclipse_application_launcher.htm reference on eclipse application launchers].<br />
<br />
<br/><br />
<br />
= Builds =<br />
<br />
The central EGit and JGit builds run on the Jenkins build infrastructure provided by the Eclipse foundation.<br />
* [https://ci.eclipse.org/egit/ EGit Jenkins instance]<br />
* [https://ci.eclipse.org/jgit/ JGit Jenkins instance]<br />
<br />
Prerequisites for the Maven build are<br />
* [https://maven.apache.org/download.html at least Maven 3.5.2]<br />
* see [https://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration<br />
* if you want to learn how Maven works start reading [https://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven or Bazel<br />
* use Java 8 to run the JGit build<br />
* JGit packaging projects (Eclipse features and p2 repository) are built using Maven and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build ==<br />
* Due to a [https://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts 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.<br />
* The local maven builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* To run the build behind a firewall follow https://maven.apache.org/guides/mini/guide-proxies.html <br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit-github<br />
<br />
[~/src/egit-github] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository<br />
<br />
in the same way you can configure a custom path for the build of egit-github to the egit p2 repository<br />
<br />
[~/src/egit-github] $ mvn clean install -Degit-site=file:/path/to/egit/org.eclipse.egit.repository/target/repository<br />
<br />
The Jenkins build uses (for SNAPSHOT builds):<br />
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/<br />
org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/<br />
<br />
If you wan to build EGit for the specific Photon (4.8) platform, consider using the <code>egit-4.8</code> target platform:<br />
[~/src/egit] $ mvn -Dtarget-platform=egit-4.8 clean install<br />
<br />
For EGit version 4.10, <code>egit-4.5</code> (Mars, Eclipse 4.5), <code>egit-4.6</code> (Neon, Eclipse 4.6), <code>egit-4.7</code> (Oxygen, Eclipse 4.7), and <code>egit-4.8</code> (Photon, Eclipse 4.8) are available. In addition <code>egit-4.8-staging</code> refers to the Photon staging repository.<br />
<br />
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.7. If you skip setting the system property <code>target-platform</code> the target platform for Eclipse 4.7 will be used.<br />
<br />
==JGit Bazel Build==<br />
Since Gerrit is built using [https://www.bazel.io/ Bazel] a Bazel build was also implemented for JGit.<br />
This simplifies working on Gerrit features which also require changes in JGit.<br />
* [https://www.bazel.io/versions/master/docs/install.html Install Bazel]<br />
* To build all libraries run<br />
bazel build :all<br />
* The following test labels are supported: api, attributes, dfs, diff, http, lfs, lfs-server, nls, notes, pack, patch, pgm, reftree, revplot, revwalk, storage, submodule, symlinks, transport, treewalk, util<br />
* To run all tests execute<br />
bazel test //...<br />
* To run specific tests, using labels:<br />
bazel test --test_tag_filters=api,dfs,revplot,treewalk //...<br />
* to rerun all tests ignoring cached test results execute<br />
bazel test //... --cache_test_results=NO<br />
* to set number of concurrent test runs<br />
bazel test //... --jobs=4<br />
* to debug a test run<br />
bazel test --test_output=streamed --test_filter=<fully qualified test method> <test target><br />
e.g.<br />
bazel test --test_output=streamed --test_filter=org.eclipse.jgit.api.GitConstructionTest.testClose //org.eclipse.jgit.test:org_eclipse_jgit_api_GitConstructionTest<br />
* to configure loggers for test runs edit org.eclipse.jgit.test/tst-rsrc/simplelogger.properties, see the [https://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html slf4j SimpleLogger documentation]<br />
* to run tests repeatedly use<br />
bazel test --runs_per_test=3 <test target><br />
* since 5.4.0 builds run with [https://github.com/google/error-prone the errorprone static analyzer] by default. If you want to enable it for older JGit versions execute<br />
bazel build --java_toolchain //tools:error_prone_warnings_toolchain :all<br />
<br />
<br />
Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://ci.eclipse.org/jgit/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://ci.eclipse.org/jgit/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://ci.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]<br />
* [https://ci.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Checking for JGit API Changes using API Baseline ==<br />
<br />
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:<br />
* 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.9.1</code>, find the p2 repository URLs [https://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<br />
* in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.9.1) and point it to the local copy of the corresponding EGit p2 repository.<br />
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems<br />
* see the [https://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.<br />
<br />
== Signing and Publishing ==<br />
EGit and JGit builds running on the JGit/EGit Jenkins instances are automatically signed <br />
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder<br />
<pre><br />
master branch: /home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
latest stable branch: /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly<br />
</pre><br />
<br />
* 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://ci.eclipse.org/egit/<br />
<br />
== Contribution to Release Train ==<br />
<br />
The release train contribution for JGit and EGit is maintained in the git repository <br />
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre><br />
in the file<br />
<pre>egit.aggrcon</pre><br />
<br />
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 />
<br/><br />
<br />
= Documentation =<br />
== JGit ==<br />
The JGit project generates a project report and javadocs using a Maven site. This Maven site is deployed to https://download.eclipse.org/jgit/site/${project.version}.<br />
E.g. http://download.eclipse.org/jgit/site/4.4.1.201607150455-r/<br />
<br />
Generating the site:<br />
'''$ mvn site:site'''<br />
<br />
Staging the site locally under ./target/staging:<br />
'''$ mvn site:stage'''<br />
<br />
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:<br />
'''$ mvn site:deploy'''<br />
The site is deployed under http://download.eclipse.org/jgit/site/${project.version}<br />
<br />
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:<br />
<server><br />
<id>jgit.website</id><br />
<username>username</username><br />
<privateKey>${user.home}/.ssh/id_rsa</privateKey><br />
<password>{<encrypted passphrase>}</password><br />
<filePermissions>664</filePermission><br />
<directoryPermissions>775</directoryPermissions><br />
<configuration></configuration><br />
</server><br />
<br />
Password encryption for Maven is described in https://maven.apache.org/guides/mini/guide-encryption.html<br />
<br />
To deploy the site from JGit HIPP (Hudson) at https://hudson.eclipse.org/jgit/ enable the Maven profile '''build-server''' and add the Maven goals '''site:site site:deploy'''.<br />
<br />
If you uploaded the site for a new release update the index<br />
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html<br />
to refer to the new release's site.<br />
<br />
== EGit ==<br />
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 [https://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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.<br />
<br />
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].<br />
<br />
Alternatively, install "Jetty 9.4.20.v20190813" from https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.4.20.v20190813/<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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''.<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":<br />
* https://download.eclipse.org/technology/swtbot/snapshots/<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== During Maven Build ===<br />
<br />
The tests are executed in the integration-test phase of the [https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html default Maven lifecycle].<br />
<br />
If you want to skip execution of UI tests (only execute core tests):<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
If you want to skip all tests:<br />
<br />
mvn clean install -Dmaven.test.skip=true<br />
<br />
== Auxilary testing tools ==<br />
<br />
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 [https://www.eclemma.org/ EclEmma] can easily visualize what part of the code is being executed.<br />
<br />
= Bugs =<br />
<br />
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":<br />
<br />
[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]<br />
<br />
[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]<br />
<br />
== Links ==<br />
=== Filing Bugs ===<br />
==== How to file bugs ==== <br />
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]] <br />
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]<br />
*[https://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham<br />
<br />
==== File a bug ====<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
==== File a bug for a vulnerability ====<br />
If you discovered a vulnerability you want to report <br />
* create a bug in Bugzilla here https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit<br />
* click "Show Advanced Fields" <br />
* and check the option "Committer-only group for handling security advisories in a closed fashion."<br />
* describe the vulnerability<br />
this will ensure that the discussion on the vulnerability is kept private between the reporter and the committer group<br />
until the project prepared a release fixing the vulnerability<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends (bugs and enhancements)<br />
!EGit <br />
!JGit<br />
|-<br />
|Open by component (date range editable)<br />
|[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] <br />
|[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]<br />
|-<br />
|Open by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|-<br />
|Assigned <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned] <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|Open and closed by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed target milestones</span> <br />
| [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]<br />
| [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]<br />
|-<br />
| Open bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open enhancements<br />
| [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]<br />
| [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]<br />
|-<br />
| Bugs with votes<br />
| [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]<br />
| [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]<br />
|-<br />
|Assigned bugs and enhancements <br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit bugs<br />
| 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]<br />
|-<br />
| New bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><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''.<br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
== Spam Bugs ==<br />
If you come across spam bugs you can request webmaster to delete them by marking them as duplicate of bug 442999.<br />
<br />
Also see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=502814 bug 502814]<br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.<br />
<br />
'''egit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''<br />
* 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 />
'''jgit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''<br />
* 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 />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
== Using Gerrit at Eclipse ==<br />
<br />
EGit and JGit projects are using [https://www.gerritcodereview.com/ Gerrit Code Review] for Git based patch submission and review. <br />
<br />
Parts of this chapter are also available in the [https://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].<br />
<br />
Both projects can accept contributions ''only'' via Gerrit. Please do not send patches by e-mail. Although both projects are mirrored to Github, EGit and JGit also cannot accept Github pull requests.<br />
<br />
=== User Account ===<br />
*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.<br />
<br />
=== Legal Paperwork ===<br />
<br />
Before your first contribution can be accepted, you need to electronically sign the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement] (ECA). The ECA is good for three years. Find more information in the [https://www.eclipse.org/legal/ecafaq.php ECA FAQ].<br />
<br />
Minimally, all Git commits you contribute must have the following:<br />
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;<br />
* Your credentials (email address) captured in the "Author" field; and<br />
* A "Signed-off-by" entry with matching credentials in the comment.<br />
* The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the [https://www.eclipse.org/legal/DCO.php Developer Certificate of Origin].<br />
<br />
In addition ensure<br />
* that the contributed code is licensed under the project license (EPL 2.0 for EGit and EDL 1.0 for JGit). This is done by putting a [https://www.eclipse.org/projects/handbook/#ip-copyright-headers copyright and license header] into every new java file. See other existing project source files for the correct content.<br />
<br />
With a valid ECA 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.<br />
<br />
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:<br />
* If it's committed: <tt>git log --shortstat</tt><br />
* If not committed: <tt>git diff --stat</tt><br />
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.<br />
<br />
Find more details about how to contribute in [https://wiki.eclipse.org/Development_Resources/Contributing_via_Git Contributing via Git (for contributors)] and [https://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions Handling Git Contributions (for committers)].<br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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 [https://help.github.com/working-with-key-passphrases use a passphrase].<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [https://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*The [https://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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[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].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** 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.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** 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.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
== Granularity of Changes ==<br />
<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
<br />
=== Branches ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedence.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
=== Braces for one-line statements ===<br />
<br />
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.:<br />
<br />
if (condition)<br />
doSomething();<br />
<br />
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:<br />
<br />
if (condition) {<br />
doSomething();<br />
}<br />
<br />
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}}.<br />
<br />
=== Removing trailing whitespace ===<br />
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}}.<br />
<br />
As a workaround, use the following sequence of commands in the Java editor to trick the save action:<br />
* remove the offending trailing whitespace<br />
* the save action re-adds the trailing whitespace<br />
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again<br />
<br />
Another workaround is to use [https://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.<br />
<br />
=== Use of the "final" modifier ===<br />
<br />
New code uses the "final" modifier in the following circumstances[https://gerrit-review.googlesource.com/c/gerrit/+/61701/].<br />
<br />
Always:<br />
* final fields: marking fields as final forces them to be initialized in the constructor or at declaration<br />
* final static fields: clearly communicates the intent<br />
* where necessary to use final variables in inner anonymous classes<br />
<br />
Optional:<br />
* final classes: use when appropriate, e.g. API restriction<br />
* final methods: similar to final classes<br />
<br />
Never:<br />
* local variables: it clutters the code, and makes the code less readable. When copying old code to new location, finals should be removed<br />
* method parameters: similar to local variables<br />
<br />
== Commit message guidelines ==<br />
<br />
*The commit message header should fit on one line. A blank line separates it from the body of the message.<br />
*The first line should be a clear and concise description about the change. It is recommended to start with the modified subsystem, followed by a colon and a description starting with capital letter and without period at the end. For example: <code>UploadPack: Use reachability checker to validate non-advertised wants</code><br />
*In case of release engineering tasks without bugzilla entries the commit message header may look like "[findbugs] Fix warning XYZ for String constructor". The prefix in brackets is an indication why this comes without a corresponding bug. <br />
*Enter a newline before providing a more detailed description about the change.<br />
*Format the commit message to have newline characters after every 60-70 characters. <br />
*Find more reasoning about commit message formatting in [https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html "A Note About Git Commit Messages"]<br />
*''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.<br />
**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. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.<br />
**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<br />
**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''.<br />
**A "Signed-off-by" can be added at the end of the commit message (see example below). Note: At the moment this footer is not required for committers, but for non-committer contributors. It may be used to list all who modified (amended, rebased, cherry-picked) this change.<br />
<br />
<br />
<pre>CommitDialog: Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
CQ: 6031<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
If you use Mylyn to fetch a bug from bugzilla, and then activate the task, the commit message will automatically be formatted exactly like requested above.<br />
<br />
== License Header ==<br />
<br />
JGit is licensed under the [https://www.eclipse.org/org/documents/edl-v10.php Eclipse Distribution License] which is a form of the [https://opensource.org/licenses/BSD-3-Clause New BSD License].<br />
Use of this license by an Eclipse project requires unanimous approval by the Board of Directors of the Eclipse Foundation<br />
which was approved in a [https://www.eclipse.org/org/foundation/boardminutes/2009_09_16_Minutes.php meeting of the board in Sep 2009].<br />
<br />
The license and copyright header to be used for JGit is<br />
<br />
/*<br />
* Copyright (c) YEAR CONTRIBUTOR[ and others]<br />
* <br />
* This program and the accompanying materials are made available under the<br />
* terms of the Eclipse Distribution License v. 1.0 which is available at<br />
* http://www.eclipse.org/org/documents/edl-v10.php.<br />
* <br />
* SPDX-License-Identifier: BSD-3-Clause<br />
*/<br />
<br />
See http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.<br />
<br />
== Copyright ==<br />
<br />
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.<br />
<br />
When there is only one copyright present (from a person or a company), like this:<br />
<br />
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org><br />
</pre><br />
<br />
Change it like this (notice the updated year):<br />
<br />
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.<br />
</pre><br />
<br />
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.<br />
<br />
When there are multiple copyright entries there, add yours as a separate line. So, given this:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
</pre><br />
<br />
Add another line:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
Copyright (C) YEAR Your Name <you@example.org><br />
</pre><br />
<br />
For new files, copy one of the existing headers and start the copyright section with your name.<br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
* Add automated tests for enhancements and bug fixes to ensure functional correctness and avoid regressions<br />
* Run all existing tests. It does not take very long.<br />
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 8 and Eclipse 4.4. You cannot use API's that are newer.<br />
<br />
== Sending patches by mail ==<br />
<br />
EGit and JGit can accept patches only via Gerrit as per [[#Contributing_Patches]].<br />
<br />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
We have build jobs '''jgit.gerrit''' on https://hudson.eclipse.org/jgit/, and '''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.<br />
<br />
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.<br />
Committers can manually trigger these jobs in the following way:<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
If you are not a committer and need to retrigger a build ask for that on the mailing list.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Jenkins&diff=433775Jenkins2019-08-19T17:30:58Z<p>Michael.keppler.gmx.de: performance hints</p>
<hr />
<div>[[File:Jenkins_logo.png|right|100px]]<br />
<br />
Jenkins is a continuous integration (CI) server. It is in use on Eclipse servers for Eclipse projects as part of the [[CBI|Common Build Infrastructure (CBI)]]. This page is about the hosted service at Eclipse.org. For more information on the project itself, or to download Jenkins, please see the [https://jenkins.io Jenkins project] page.<br />
<br />
= General Information =<br />
<br />
Jenkins instances are maintained by the Eclipse Webmasters/Release Engineers.<br />
<br />
* List of Jenkins Instances Per Project (JIPP):<br />
** https://ci.eclipse.org/ (bare-metal infra and cluster-based infra '''after migration''')<br />
** https://ci.polarsys.org/ (bare-metal infra)<br />
** https://jenkins.eclipse.org/ (cluster-based infra - based on RedHat OpenShift Kubernetes and CloudBees Core aka CloudBees Jenkins Enterprise)<br />
** https://ci-staging.eclipse.org/ (cluster-based infra, temporary domain during migration, while old and new JIPP are both still active)<br />
<br />
== Asking for Help ==<br />
<br />
* Need help actually building your code: ask your project mentors, or ask on the Common Build mailing list (cbi-dev). There are no dumb questions.<br />
* Subscribe to cbi-dev here: https://dev.eclipse.org/mailman/listinfo/cbi-dev<br />
<br />
== Requesting a JIPP instance for CBI ==<br />
<br />
Please see [[CBI#Requesting_a_JIPP_instance]]<br />
<br />
= Jenkins configuration and tools (clustered infra) =<br />
<br />
== Tools (and locations on the default JNLP agent container) ==<br />
<br />
=== Apache Maven ===<br />
<br />
* apache-maven-latest <code>/opt/tools/apache-maven/latest</code> (= apache-maven-3.6.0)<br />
* apache-maven-3.6.1 <code>/opt/tools/apache-maven/3.6.1</code> ('''Please note: Version 3.6.1 breaks Tycho's dependency resolution, therefore it's not recommended to use it.''')<br />
* apache-maven-3.6.0 <code>/opt/tools/apache-maven/3.6.0</code><br />
* apache-maven-3.5.4 <code>/opt/tools/apache-maven/3.5.4</code><br />
* apache-maven-3.3.9 <code>/opt/tools/apache-maven/3.3.0</code><br />
* apache-maven-3.2.5 <code>/opt/tools/apache-maven/3.2.5</code><br />
<br />
=== JDK ===<br />
<br />
==== OpenJDK ====<br />
<br />
The binaries listed below come from http://jdk.java.net. These are production-ready open-source builds of the Java Development Kit, an implementation of the Java SE Platform under the [http://openjdk.java.net/legal/gplv2+ce.html GNU General Public License, version 2, with the Classpath Exception]. See the differences between these binaries and Oracle's one for version 11 onward on [https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later Oracle's director of product management blog post].<br />
<br />
* openjdk-latest <code>/opt/tools/java/openjdk/latest</code>(= openjdk-jdk12-latest)<br />
* openjdk-jdk13ea-latest <code>/opt/tools/java/openjdk/jdk-13ea/latest</code> = '''13ea+6'''<br />
* openjdk-jdk12-latest <code>/opt/tools/java/openjdk/jdk-12/latest</code> = '''12 GA'''<br />
* openjdk-jdk11-latest <code>/opt/tools/java/openjdk/jdk-11/latest</code> = '''11.0.2'''<br />
* openjdk-jdk10-latest <code>/opt/tools/java/openjdk/jdk-10/latest</code> = '''10.0.2'''<br />
* openjdk-jdk9-latest <code>/opt/tools/java/openjdk/jdk-9/latest</code> = '''9.0.4'''<br />
<br />
==== AdoptOpenJDK ====<br />
<br />
The binaries listed below come from https://adoptopenjdk.net. These OpenJDK binaries are built from a fully open source set of [https://github.com/AdoptOpenJDK/openjdk-build build scripts] and infrastructure.<br />
<br />
===== With HotSpot =====<br />
<br />
* adoptopenjdk-hotspot-latest <code>/opt/tools/java/adoptopenjdk/hotspot-latest</code>(= adoptopenjdk-hotspot-jdk12-latest)<br />
* adoptopenjdk-hotspot-jdk12-latest <code>/opt/tools/java/adoptopenjdk/hotspot-jdk-12/latest</code> = '''12 GA'''<br />
* adoptopenjdk-hotspot-jdk11-latest <code>/opt/tools/java/adoptopenjdk/hotspot-jdk-11/latest</code> = '''11.0.2'''<br />
* adoptopenjdk-hotspot-jdk10-latest <code>/opt/tools/java/adoptopenjdk/hotspot-jdk-10/latest</code> = '''10.0.2'''<br />
* adoptopenjdk-hotspot-jdk9-latest <code>/opt/tools/java/adoptopenjdk/hotspot-jdk-9/latest</code> = '''9.0.4'''<br />
* adoptopenjdk-hotspot-jdk8-latest <code>/opt/tools/java/adoptopenjdk/hotspot-jdk-8/latest</code> = '''1.8.0u202'''<br />
<br />
===== With OpenJ9 =====<br />
<br />
The binaries listed below replace the traditional HotSpot implementation of the Java Virtual Machine implementation with [https://www.eclipse.org/openj9/ Eclipse OpenJ9]. Eclipse OpenJ9 is a high performance, scalable, Java virtual machine implementation that is fully compliant with the Java Virtual Machine Specification.<br />
<br />
* adoptopenjdk-openj9-latest <code>/opt/tools/java/adoptopenjdk/openj9-latest</code>(= adoptopenjdk-openj9-jdk12-latest)<br />
* adoptopenjdk-openj9-jdk12-latest <code>/opt/tools/java/adoptopenjdk/openj9-jdk-12/latest</code> = '''12 GA'''<br />
* adoptopenjdk-openj9-jdk11-latest <code>/opt/tools/java/adoptopenjdk/openj9-jdk-11/latest</code> = '''11.0.2'''<br />
* adoptopenjdk-openj9-jdk10-latest <code>/opt/tools/java/adoptopenjdk/openj9-jdk-10/latest</code> = '''10.0.2'''<br />
* adoptopenjdk-openj9-jdk9-latest <code>/opt/tools/java/adoptopenjdk/openj9-jdk-9/latest</code> = '''9.0.4'''<br />
* adoptopenjdk-openj9-jdk8-latest <code>/opt/tools/java/adoptopenjdk/openj9-jdk-8/latest</code> = '''1.8.0u202'''<br />
<br />
==== Oracle ====<br />
<br />
The binaries listed below come from the [https://www.oracle.com/technetwork/java/javase/downloads/index.html Oracle Technology Network]. Note that Oracle JDK from version 11 onward is licensed under the terms of the new [https://www.oracle.com/technetwork/java/javase/terms/license/javase-license.html Oracle Technology Network (OTN) License Agreement for Oracle Java SE] that ''is substantially different from the licenses under which previous versions of the JDK were offered''. Oracle JDK 10 and earlier versions were released under the [https://www.oracle.com/technetwork/java/javase/terms/license/index.html Oracle Binary Code License (BCL) for Java SE]. <br />
<br />
As such, starting with JDK 11, the Eclipse Foundation ''will not'' provide any version of the Oracle JDK licensed under the -commercial- OTN terms. Previous versions listed below, will stay available as is. See the ''cosmetic and packaging differences'' between Oracle's OpenJDK Builds (GPL+CE) — simply named [[#OpenJDK|OpenJDK]] above — and Oracle JDK (OTN) on [https://blogs.oracle.com/java-platform-group/oracle-jdk-releases-for-java-11-and-later Oracle Director of Product Management's blog post].<br />
<br />
* oracle-latest <code>/opt/tools/java/oracle/latest</code> (= oracle-jdk10-latest)<br />
* oracle-jdk10-latest <code>/opt/tools/java/oracle/jdk-10/latest</code> = '''10.0.2'''<br />
* oracle-jdk9-latest <code>/opt/tools/java/oracle/jdk-9/latest</code> = '''9.0.4'''<br />
* oracle-jdk8-latest <code>/opt/tools/java/oracle/jdk-8/latest</code> = '''1.8.0u202'''<br />
* oracle-jdk7-latest <code>/opt/tools/java/oracle/jdk-7/latest</code> = '''1.7.0u80'''<br />
* oracle-jdk6-latest <code>/opt/tools/java/oracle/jdk-6/latest</code> = '''1.6.0u45'''<br />
* oracle-jdk5-latest <code>/opt/tools/java/oracle/jdk-5/latest</code> = '''1.5.0u22'''<br />
* oracle-jdk1.4-latest <code>/opt/tools/java/oracle/jdk-1.4/latest</code> = '''1.4.2u19'''<br />
<br />
==== IBM ====<br />
<br />
The binaries listed below come from [https://developer.ibm.com/javasdk/downloads/ IBM SDK, Java Technology Edition].<br />
<br />
* ibm-latest <code>/opt/tools/java/ibm/latest</code> (= ibm-jdk8-latest)<br />
* ibm-jdk8-latest <code>/opt/tools/java/ibm/jdk-8/latest</code> = '''8.0.5.27'''<br />
<br />
=== Ant ===<br />
<br />
* apache-ant-latest (1.10.5, automatically installed from Apache server)<br />
<br />
== Default plugins - CJE (jenkins.eclipse.org/xxx) ==<br />
<br />
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4"><br />
* ace-editor<br />
* analysis-core<br />
* ant<br />
* antisamy-markup-formatter<br />
* apache-httpcomponents-client-4-api<br />
* async-http-client<br />
* authentication-tokens<br />
* aws-credentials<br />
* aws-java-sdk<br />
* blueocean-commons<br />
* bouncycastle-api<br />
* branch-api<br />
* build-timeout<br />
* cloudbees-assurance<br />
* cloudbees-blueocean-default-theme<br />
* cloudbees-folder<br />
* cloudbees-folders-plus<br />
* cloudbees-groovy-view<br />
* cloudbees-jsync-archiver<br />
* cloudbees-license<br />
* cloudbees-monitoring<br />
* cloudbees-nodes-plus<br />
* cloudbees-ssh-slaves<br />
* cloudbees-support<br />
* cloudbees-template<br />
* cloudbees-uc-data-api<br />
* cloudbees-view-creation-filter<br />
* cloudbees-workflow-template<br />
* cloudbees-workflow-ui<br />
* command-launcher<br />
* conditional-buildstep<br />
* config-file-provider<br />
* credentials<br />
* credentials-binding<br />
* dashboard-view<br />
* disk-usage<br />
* display-url-api<br />
* docker-commons<br />
* docker-workflow<br />
* durable-task<br />
* email-ext<br />
* envinject<br />
* envinject-api<br />
* extended-read-permission<br />
* external-monitor-job<br />
* extra-columns<br />
* findbugs<br />
* form-element-path<br />
* gerrit-trigger<br />
* ghprb<br />
* git<br />
* git-client<br />
* git-parameter<br />
* git-server<br />
* github<br />
* github-api<br />
* github-branch-source<br />
* gradle<br />
* greenballs<br />
* handlebars<br />
* icon-shim<br />
* infradna-backup<br />
* jackson2-api<br />
* javadoc<br />
* jdk-tool<br />
* jobConfigHistory<br />
* jquery<br />
* jquery-detached<br />
* jsch<br />
* junit<br />
* kube-agent-management<br />
* kubernetes<br />
* kubernetes-credentials<br />
* ldap<br />
* mailer<br />
* mapdb-api<br />
* matrix-auth<br />
* matrix-project<br />
* maven-plugin<br />
* metrics<br />
* momentjs<br />
* nectar-license<br />
* nectar-rbac<br />
* node-iterator-api<br />
* operations-center-agent<br />
* operations-center-client<br />
* operations-center-cloud<br />
* operations-center-context<br />
* pam-auth<br />
* parameterized-trigger<br />
* pipeline-build-step<br />
* pipeline-graph-analysis<br />
* pipeline-input-step<br />
* pipeline-milestone-step<br />
* pipeline-model-api<br />
* pipeline-model-declarative-agent<br />
* pipeline-model-definition<br />
* pipeline-model-extensions<br />
* pipeline-rest-api<br />
* pipeline-stage-step<br />
* pipeline-stage-tags-metadata<br />
* pipeline-stage-view<br />
* plain-credentials<br />
* promoted-builds<br />
* rebuild<br />
* resource-disposer<br />
* run-condition<br />
* scm-api<br />
* script-security<br />
* ssh-agent<br />
* ssh-credentials<br />
* ssh-slaves<br />
* structs<br />
* support-core<br />
* timestamper<br />
* token-macro<br />
* unique-id<br />
* variant<br />
* wikitext<br />
* windows-slaves<br />
* workflow-aggregator<br />
* workflow-api<br />
* workflow-basic-steps<br />
* workflow-cps<br />
* workflow-cps-checkpoint<br />
* workflow-cps-global-lib<br />
* workflow-durable-task-step<br />
* workflow-job<br />
* workflow-multibranch<br />
* workflow-scm-step<br />
* workflow-step-api<br />
* workflow-support<br />
* ws-cleanup<br />
* xvnc<br />
</div><br />
<br />
== Default plugins - Jiro (ci-staging.eclipse.org/xxx and ci.eclipse.org/xxx) ==<br />
<br />
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4"><br />
* ace-editor<br />
* analysis-core<br />
* ant<br />
* antisamy-markup-formatter<br />
* apache-httpcomponents-client-4-api<br />
* authentication-tokens<br />
* bouncycastle-api<br />
* branch-api<br />
* build-timeout<br />
* cloudbees-folder<br />
* command-launcher<br />
* conditional-buildstep<br />
* config-file-provider<br />
* configuration-as-code<br />
* configuration-as-code-support<br />
* credentials<br />
* credentials-binding<br />
* display-url-api<br />
* docker-commons<br />
* docker-workflow<br />
* durable-task<br />
* email-ext<br />
* extended-read-permission<br />
* extra-columns<br />
* findbugs<br />
* gerrit-trigger<br />
* ghprb<br />
* git<br />
* git-client<br />
* git-parameter<br />
* git-server<br />
* github<br />
* github-api<br />
* greenballs<br />
* handlebars<br />
* jackson2-api<br />
* javadoc<br />
* jdk-tool<br />
* jobConfigHistory<br />
* jquery<br />
* jquery-detached<br />
* jsch<br />
* junit<br />
* kubernetes<br />
* kubernetes-credentials<br />
* ldap<br />
* lockable-resources<br />
* mailer<br />
* matrix-auth<br />
* matrix-project<br />
* maven-plugin<br />
* momentjs<br />
* parameterized-trigger<br />
* pipeline-build-step<br />
* pipeline-graph-analysis<br />
* pipeline-input-step<br />
* pipeline-maven<br />
* pipeline-milestone-step<br />
* pipeline-model-api<br />
* pipeline-model-declarative-agent<br />
* pipeline-model-definition<br />
* pipeline-model-extensions<br />
* pipeline-rest-api<br />
* pipeline-stage-step<br />
* pipeline-stage-tags-metadata<br />
* pipeline-stage-view<br />
* plain-credentials<br />
* promoted-builds<br />
* rebuild<br />
* resource-disposer<br />
* run-condition<br />
* scm-api<br />
* script-security<br />
* simple-theme-plugin<br />
* sonar<br />
* ssh-agent<br />
* ssh-credentials<br />
* ssh-slaves<br />
* structs<br />
* timestamper<br />
* token-macro<br />
* variant<br />
* windows-slaves<br />
* workflow-aggregator<br />
* workflow-api<br />
* workflow-basic-steps<br />
* workflow-cps<br />
* workflow-cps-global-lib<br />
* workflow-durable-task-step<br />
* workflow-job<br />
* workflow-multibranch<br />
* workflow-scm-step<br />
* workflow-step-api<br />
* workflow-support<br />
* ws-cleanup<br />
* xvnc<br />
</div><br />
<br />
== FAQ ==<br />
<br />
{{important|FAQ|The following FAQ only applies to Eclipse projects running their builds on the '''new cluster-based infrastructure'''. It does not apply to projects running on the old infrastructure.}}<br />
<br />
=== Is my project's JIPP running on the old infra, CJE or Jiro? ===<br />
<br />
If your JIPP is hosted on ci.eclipse.org/<name of your project>, you can check the list of JIPPs on https://ci.eclipse.org:<br />
* if it says <project-name> (hipp1-10), it's on the old infra<br />
* if it says <project-name> (openshift), it's on the new infra (Jiro)<br />
<br />
<br />
If your JIPP is hosted on jenkins.eclipse.org/<name of your project>, it's hosted on the new infra (CJE).<br />
<br />
If your JIPP is currently hosted on ci-staging.eclipse.org, it's in the migration process and will be hosted at ci.eclipse.org, once the migration is done.<br/><br />
See also here: https://wiki.eclipse.org/CBI/Jenkins_Migration_FAQ#What.E2.80.99s_the_plan.3F.<br />
<br />
All projects on CJE will be eventually migrated to Jiro.<br />
<br />
For migration specific question, please see also https://wiki.eclipse.org/CBI/Jenkins_Migration_FAQ.<br />
<br />
=== How do I run a Java build on the new infra? ===<br />
<br />
The most simple way is to create a Jenkinsfile in your git repo and create a multi branch pipeline job in your Jenkins instance. See https://jenkins.io/doc/pipeline/tour/hello-world/ for more information. See below a simple Jenkinsfile. Note that the full list of available tools name can be found in the [[#Tools (and locations on the default JNLP agent container)|tools]] section of this page.<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent any<br />
tools {<br />
maven 'apache-maven-latest'<br />
jdk 'adoptopenjdk-hotspot-jdk8-latest'<br />
}<br />
stages {<br />
stage('Build') {<br />
steps {<br />
sh '''<br />
java -version<br />
mvn -v<br />
'''<br />
}<br />
}<br />
}<br />
post {<br />
// send a mail on unsuccessful and fixed builds<br />
unsuccessful { // means unstable || failure || aborted<br />
emailext subject: 'Build $BUILD_STATUS $PROJECT_NAME #$BUILD_NUMBER!', <br />
body: '''Check console output at $BUILD_URL to view the results.''',<br />
recipientProviders: [culprits(), requestor()], <br />
to: 'other.recipient@domain.org'<br />
}<br />
fixed { // back to normal<br />
emailext subject: 'Build $BUILD_STATUS $PROJECT_NAME #$BUILD_NUMBER!', <br />
body: '''Check console output at $BUILD_URL to view the results.''',<br />
recipientProviders: [culprits(), requestor()], <br />
to: 'other.recipient@domain.org'<br />
}<br />
}<br />
}<br />
</source><br />
<br />
=== How do I run UI-tests on the new infra? ===<br />
<br />
For UI tests, there are two scenarios:<br />
* In general, you can use a custom docker image and Jenkins pipelines, see https://wiki.eclipse.org/Jenkins#How_do_I_run_my_build_in_a_custom_container.3F.<br />
* To ease the migration/transition, we provide two pod templates:<br />
** a '''basic''' UI-test pod template (label: "ui-test"). This image only provides a minimal UI test environment.<br />
** a migration pod template (label: "migration"). This docker image should be quite close to the environment on the old infrastructure.<br />
*If your project requires specific dependencies, in most cases, you will need to use the migration pod template or roll your own.<br />
<br />
<br />
For freestyle jobs the label can be specified in the job configuration under "Restrict where this project can be run".<br />
<br />
<br />
Example for pipeline jobs:<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'ui-test'<br />
}<br />
}<br />
tools {<br />
maven 'apache-maven-latest'<br />
jdk 'adoptopenjdk-hotspot-jdk8-latest'<br />
}<br />
stages {<br />
stage('Build') {<br />
steps {<br />
wrap([$class: 'Xvnc', takeScreenshot: false, useXauthority: true]) {<br />
sh 'mvn clean verify'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
<br />
=== My builds fails with: 'FATAL: Cannot run program "Xvnc"', what do I need to do? ===<br />
<br />
You are most likely running UI tests that require a desktop environment and a VNC server. The default pod template does not provide such an environment. Therefore you will need to use a different pod template or a custom docker image.<br />
<br />
'''The migration pod template (label: "migration") can be used for UI tests.''' This docker image should be quite close to the environment on the old infrastructure. If you don't have any other dependencies on the environment, you can also try the much smaller & leaner UI test pod template (label: ui-test).<br />
<br />
See https://wiki.eclipse.org/Jenkins#How_do_I_run_UI-tests_on_the_new_infra.3F on how the pod template can be used with freestyle or pipeline jobs.<br />
<br />
=== How do I run my build in a custom container? ===<br />
<br />
You need to use a Jenkins pipeline to do so. Then you can specify a Kubernetes pod template. See an example below.<br />
<br />
You can either use already existing "official" docker images, for example the <code>maven:<version>-alpine</code> images or create your own custom docker image.<br />
Docker images need to be hosted on https://hub.docker.com or another public container registry (e.g. https://quay.io).<br />
<br />
'''Please note:''' Currently, docker images can not be '''built''' (as in created) on our Jenkins CI instances.<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
command:<br />
- cat<br />
tty: true<br />
- name: php<br />
image: php:7.2.10-alpine<br />
command:<br />
- cat<br />
tty: true<br />
- name: hugo<br />
image: eclipsecbi/hugo:0.42.1<br />
command:<br />
- cat<br />
tty: true<br />
"""<br />
}<br />
}<br />
stages {<br />
stage('Run maven') {<br />
steps {<br />
container('maven') {<br />
sh 'mvn -version'<br />
}<br />
container('php') {<br />
sh 'php -version'<br />
}<br />
container('hugo') {<br />
sh 'hugo -version'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
See the [https://github.com/jenkinsci/kubernetes-plugin Kubernetes Jenkins plugin] for more documentation.<br />
<br />
=== Why are there no build executors? Why are build executors offline/suspended and/or builds never start? ===<br />
<br />
On our cluster-based infrastructure all build executors/agents/pods (except on dedicated agents) are dynamically spun up. This usually takes a little while. Therefore the build executor status panel might show something like<br />
* "(pending—Waiting for next available executor)" or<br />
* "my-agent-abcd123 is offline or suspended"<br />
for a few seconds, before the build starts. We've opened [https://issues.jenkins-ci.org/browse/JENKINS-56307 a ticket with a suggestion on the Jenkins project] to speed up the provisioning process. Feel free to vote on this issue if you feel it is important for you.<br />
<br />
If such a message is shown for more than ~5 minutes, you can safely assume that something is wrong with the pod/container config. For example: a docker image can't be found because there is a typo in the name or the tag was wrong.<br />
<br />
=== What is killing my build? I'm using custom containers! ===<br />
<br />
First, please get familiarized with how [https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/ Kubernetes assigns memory resources to containers and pods]<br />
<br />
Then, you should know that, as soon as you run your build in a custom Kubernetes agent, Jenkins adds a container named "jnlp" that will handle the connection between the pod agent and the master. The resources assigned to this "jnlp" container come from a default values we set for you. Because we know the "jnlp" container does not use need of cpu and memory, we set the default values for all containers to low values (about 512MiB and 0.25 vCPU). This way, we're sure that the "jnlp" container won't uselessly consume too much resources that are allocated to your project. But this has the negative effect that, if you don't effectively specify the resources requests and limits in your pod template, your custom containers will also inherit those values (which are probably too low for you). To overcome the issue, you need to specify those values in your pod template like:<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
command:<br />
- cat<br />
tty: true<br />
resources:<br />
limits:<br />
memory: "2Gi"<br />
cpu: "1"<br />
requests:<br />
memory: "2Gi"<br />
cpu: "1"<br />
"""<br />
}<br />
}<br />
stages {<br />
stage('Run maven') {<br />
steps {<br />
container('maven') {<br />
sh 'mvn -version'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
Note that if you run multiple containers, you need to specify the limits for each. <br />
<br />
We plan to develop some tooling to automatically inject correct default values for your custom containers depending on the resource quotas and the concurrency level (i.e. how many agent can run at once) assigned to your project [https://github.com/eclipse-cbi/jiro/issues/20 GitHub Issue #20].<br />
<br />
=== How do I deploy artifacts to download.eclipse.org? ===<br />
<br />
You cannot just <code>cp</code> stuff to a folder. You need to do that with <code>ssh</code>. The first thing to do is to [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins&short_desc=Grant%20access%20to%20projects%20storage%20service%20to%20the%20Jenkins%20instance%20of%20project%20XXXXXX request write access] to the projects storage service for your Jenkins instance. This service provide access to the Eclipse Foundation file servers storage:<br />
<br />
* <code>/home/data/httpd/download.eclipse.org</code><br />
* <code>/home/data/httpd/archive.eclipse.org</code><br />
* <code>/home/data/httpd/download.polarsys.org</code><br />
* <code>/home/data/httpd/download.locationtech.org</code><br />
<br />
Then, we will configure your Jenkins instance with SSH credentials. Depending on how you run your build, the way you will use them are different. See the different cases below.<br />
<br />
==== Freestyle job ====<br />
<br />
You need to activate the ''SSH Agent'' plugin in your job configuration and select the proper credentials <code>genie.''projectname'' (<nowiki>ssh://projects-storage.eclipse.org</nowiki>)</code>.<br />
<br />
[[File:project-storage-ssh-agent.png|800px]]<br />
<br />
Then you use <code>ssh</code>, <code>scp</code> and <code>sftp</code> commands to deploy artifacts to the server, e.g.,<br />
<br />
<source lang="bash" style="border:1px solid;padding: 5px; margin: 5px;"><br />
scp target/my_artifact.jar genie.<projectname>@projects-storage.eclipse.org:/home/data/httpd/download.eclipse.org/<projectname>/<br />
ssh genie.<projectname>@projects-storage.eclipse.org ls -al /home/data/httpd/download.eclipse.org/<projectname</<br />
</source><br />
<br />
==== Pipeline job without custom pod template ====<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent any<br />
<br />
stages {<br />
stage('stage 1') {<br />
...<br />
}<br />
stage('Deploy') {<br />
steps {<br />
sshagent ( ['projects-storage.eclipse.org-bot-ssh']) {<br />
sh '''<br />
ssh genie.projectname@projects-storage.eclipse.org rm -rf /home/data/httpd/download.eclipse.org/projectname/snapshots<br />
ssh genie.projectname@projects-storage.eclipse.org mkdir -p /home/data/httpd/download.eclipse.org/projectname/snapshots<br />
scp -r repository/target/repository/* genie.projectname@projects-storage.eclipse.org:/home/data/httpd/download.eclipse.org/projectname/snapshots<br />
'''<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
==== Pipeline job with custom pod template ====<br />
<br />
{{important|JNLP container|A 'jnlp' container is automatically added, when a custom pod template is used to ensure connectivity between the Jenkins master and the pod. If you want to deploy files to download.eclipse.org, you only need to specify the known-hosts volume for the JNLP container (as seen below) to avoid "host verification failed" errors.}}<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-pod'<br />
yaml '''<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
command:<br />
- cat<br />
tty: true<br />
- name: jnlp<br />
volumeMounts:<br />
- name: volume-known-hosts<br />
mountPath: /home/jenkins/.ssh<br />
volumes:<br />
- name: volume-known-hosts<br />
configMap:<br />
name: known-hosts<br />
'''<br />
}<br />
}<br />
stages {<br />
stage('Build') {<br />
steps {<br />
container('maven') {<br />
sh 'mvn clean verify'<br />
}<br />
}<br />
}<br />
stage('Deploy') {<br />
steps {<br />
container('jnlp') {<br />
sshagent ( ['projects-storage.eclipse.org-bot-ssh']) {<br />
sh '''<br />
ssh genie.projectname@projects-storage.eclipse.org rm -rf /home/data/httpd/download.eclipse.org/projectname/snapshots<br />
ssh genie.projectname@projects-storage.eclipse.org mkdir -p /home/data/httpd/download.eclipse.org/projectname/snapshots<br />
scp -r repository/target/repository/* genie.projectname@projects-storage.eclipse.org:/home/data/httpd/download.eclipse.org/projectname/snapshots<br />
'''<br />
}<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
=== My build fails with "No user exists for uid 1000100000", what's the issue? ===<br />
<br />
First, you need to know that we run containers using an arbitrarily assigned user ID (1000100000) in our OpenShift cluster. This is for security reasons.<br />
<br />
Unfortunately, most of images you can find on DockerHub (including official images) do not support running as an arbitrary user. Actually, most of them expect to run as root, which is definitely a [https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b bad practice]. See also question below about [[#How can I run my build in a container with root privileges?|how to run a container as root]].<br />
<br />
Moreover, some programs like <code>ssh</code> search for a mapping between the user ID (1000100000) and a user name on the system (here a container). It's very rare that any container anticipate this need and actually created a user with ID=1000100000. To avoid this error, you need to customize the image. OpenShift publishes [https://docs.openshift.com/container-platform/3.9/creating_images/guidelines.html guidelines with best practices] about how to create Docker images. More specifically, see the section about how to [https://docs.openshift.com/container-platform/3.9/creating_images/guidelines.html#use-uid support running with arbitrary user ID].<br />
<br />
In order to make your image call the uid_entrypoint as listed in the link above, you will need to add it to the command directive in the pod template, e.g.:<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-pod'<br />
yaml '''<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: custom-container<br />
image: 'custom/image'<br />
command: [ "/usr/local/bin/uid_entrypoint" ]<br />
args: [ "cat" ]<br />
tty: true<br />
'''<br />
}<br />
}<br />
stages {<br />
stage('Stage 1') {<br />
steps {<br />
container('custom-container') {<br />
sh 'whoami'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
If you want to see in practice, have a look at some images we've defined to run in the cluster on this [https://github.com/eclipse-cbi/dockerfiles GitHub repository].<br />
<br />
=== How can I run my build in a container with root privileges? ===<br />
<br />
Unfortunately, for security reasons, you cannot do that. We run an infrastructure open to the internet, which potentially runs stuff from non-trusted code (e.g., PR) so we need to follow a strict policy to protect the common good.<br />
<br />
More specifically, we run containers using an arbitrarily assigned user ID (e.g. 1000100000) in our OpenShift cluster. The group ID is always root (0) though. The [https://docs.openshift.com/container-platform/3.9/admin_guide/manage_scc.html security context constraints] we use for running projects' containers is "restricted". You cannot change this level from your podTemplate.<br />
<br />
Unfortunately, most of images you can find on DockerHub (including official images) do not support running as an arbitrary user. Actually, most of them expect to run as root, which is definitely a [https://medium.com/@mccode/processes-in-containers-should-not-run-as-root-2feae3f0df3b bad practice].<br />
<br />
OpenShift publishes [https://docs.openshift.com/container-platform/3.9/creating_images/guidelines.html guidelines with best practices] about how to create Docker images. More specifically, see the section about how to [https://docs.openshift.com/container-platform/3.9/creating_images/guidelines.html#use-uid support running with arbitrary user ID].<br />
<br />
To test if an image is ready to be run with an arbitrarily assigned user ID, you can try to start it with the following command line:<br />
<br />
$ docker run -it --rm -u $((1000100000 + RANDOM % 100000)):0 image/name:tag<br />
<br />
=== I want to build a custom Docker image (with <code>docker build</code>), but it does not work. What should I do? === <br />
You cannot currently build images on the cluster (i.e. <code>docker build</code> does not work). We plan to address this shortcoming shortly.<br />
<br />
=== My build fails with "Host key verification failed", what should I do? ===<br />
<br />
As long as you stay in the default <code>jnlp</code> docker image (i.e. use a Freestyle Job or a Pipeline job without custom pod template), you'll benefit from our existing configuration where we mount a <code>known_hosts</code> file in the <code>~/.ssh</code> folder of all containers.<br />
<br />
If you define a custom pod template, you need to add some configuration to mount this [https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/ config map] in your containers. The only thing that you have to know is the config map name '''known-hosts''' and mount it at the proper location <code>/home/jenkins/.ssh</code>. <br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
command:<br />
- cat<br />
tty: true<br />
volumeMounts:<br />
- name: volume-known-hosts<br />
mountPath: /home/jenkins/.ssh<br />
volumes:<br />
- name: volume-known-hosts<br />
configMap:<br />
name: known-hosts<br />
"""<br />
}<br />
}<br />
stages {<br />
...<br />
}<br />
}<br />
</source><br />
<br />
Currently, the known_hosts file we provide as the key for the following sites:<br />
* git.eclipse.org:22<br />
* git.eclipse.org:29418<br />
* build.eclipse.org<br />
* github.com<br />
<br />
If you need any other site to be added, feel free to [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins open a request].<br />
<br />
=== How do I use the local Nexus server as proxy for Maven Central (artifact caching)? ===<br />
<br />
Every JIPP on the new infra already has a Maven settings file set up that specifies our [https://repo.eclipse.org local Nexus instance] as cache for Maven Central.<br />
<br />
{{important|Jiro|In [https://github.com/eclipse-cbi/jiro Jiro] this works out of the box for the default pod templates (labels: jnlp, migration, ui-test). No additional configuration is required for Freestyle and Pipeline jobs. For custom containers, see below: [https://wiki.eclipse.org/Jenkins#Custom_container_on_Jiro Custom container on Jiro]}}<br />
<br />
Unfortunately, for instances on CJE (CloudBees Core) we have not found a way to make this the default Maven settings file for '''all''' Maven builds. That's why it needs to be specified manually.<br />
<br />
The name of the settings file has the format <code>settings-<projectshortname>.xml</code>, e.g. settings-metro.xml for the Eclipse Metro project.<br />
<br />
==== Freestyle job ====<br />
<br />
In a freestyle job the settings file needs to be injected. It can either be used with a variable (e.g. MVNSETTINGS), which you can reference later with <code>mvn -s $MVNSETTINGS clean verify [...]</code> in a shell build step.<br />
<br />
[[File:ProvideConfigFiles_variable_.png|500px]]<br />
<br />
Or you can set the target to <code>/home/jenkins/.m2/settings.xml</code>. The settings.xml will then be picked up automatically by Maven builds.<br />
<br />
[[File:ProvideConfigFiles_target.png|500px]]<br />
<br />
==== Pipeline job ====<br />
<br />
In a pipeline job you have to specify the fileId of the Maven settings file as an UUID. You can find out the correct fileId by using the pipeline syntax generator and choosing "configFileProvider: Provide Configuration files" as the sample step.<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
[...]<br />
configFileProvider([configFile(fileId: '5f77ec66-dc5e-4d29-999f-311501789ba0', variable: 'MVN_SETTINGS')]) {<br />
sh "${mvnHome}/bin/mvn -s $MVN_SETTINGS clean verify"<br />
}<br />
[...]<br />
</source><br />
<br />
==== Custom container on Jiro ====<br />
You need to add the settings-xml volume, like shown below. Please note, the m2-repo volume is required as well, otherwise /home/jenkins/.m2/repository is not writable.<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
tty: true<br />
command:<br />
- cat<br />
volumeMounts:<br />
- name: settings-xml<br />
mountPath: /home/jenkins/.m2/settings.xml<br />
subPath: settings.xml<br />
readOnly: true<br />
- name: m2-repo<br />
mountPath: /home/jenkins/.m2/repository<br />
volumes:<br />
- name: settings-xml<br />
configMap: <br />
name: m2-dir<br />
items:<br />
- key: settings.xml<br />
path: settings.xml<br />
- name: m2-repo<br />
emptyDir: {}<br />
"""<br />
}<br />
}<br />
stages {<br />
stage('Run maven') {<br />
steps {<br />
container('maven') {<br />
sh 'mvn -version'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
=== How can artifacts be deployed to Nexus OSS (repo.eclipse.org)? ===<br />
<br />
If your project does not have it's own repo on Nexus yet, then simply [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Nexus file a bug] and specify what project you'd like a Nexus repo for.<br />
<br />
If your project does have it's own repo on Nexus already, then you can use Maven (or Gradle) to deploy your artifacts. This is also described here: https://wiki.eclipse.org/Services/Nexus#Deploying_artifacts_to_repo.eclipse.org.<br />
<br />
{{Note|No separate Maven settings file required| Please note, on our new infra (Jiro), you don't need to specify a separate Maven settings file for deployment to Nexus. All information is contained in the default Maven settings file located at <code>/home/jenkins/.m2/settings.xml.</code>}}<br />
<br />
=== How can artifacts be deployed to OSSRH / Maven Central? ===<br />
<br />
Deploying artifacts to OSSRH (OSS Repository Hosting provided by Sonatype) requires an account at OSSRH. It is also required to sign all artifacts with GPG. The Eclipse IT team will set this up for the project.<br/><br />
'''Please [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins&short_desc=OSSRH%20setup%20for%20project%20XXX file a bug] for this first.'''<br />
<br />
==== Required steps for a freestyle job ====<br />
<br />
{{Note|Note| Please note, the following instructions '''only''' work on the new infra (Jiro!). They do not work on CJE (jenkins.eclipse.org). Instructions for CJE can be found here: [[EE4J_Build]].}}<br />
<br />
{| class="wikitable"<br />
|- style="vertical-align:top;"<br />
|1. Insert <code>secret-subkeys.asc</code> as secret file in job<br />
| [[File:InjectSecretFile2.png]]<br />
|- style="vertical-align:top;"<br />
|2. Import GPG keyring with <code>--batch</code> and trust the keys non-interactively in a shell build step (before the Maven call)<code><br />
gpg --batch --import "${KEYRING}"<br />
for fpr in $(gpg --list-keys --with-colons | awk -F: '/fpr:/ {print $10}' | sort -u);<br />
do<br />
echo -e "5\ny\n" | gpg --batch --command-fd 0 --expert --edit-key $fpr trust;<br />
done<br />
</code><br />
|[[File:GpgImport.png|700px]]<br />
|- style="vertical-align:top;"<br />
|3. Since a newer GPG version (> 2.1+) is used on the new infra, it's required to add <code>--pinentry-mode loopback</code> as gpg argument in the pom.xml:<br />
<plugin><br />
<groupId>org.apache.maven.plugins</groupId><br />
<artifactId>maven-gpg-plugin</artifactId><br />
<version>1.6</version><br />
<executions><br />
<execution><br />
<id>sign-artifacts</id><br />
<phase>verify</phase><br />
<goals><br />
<goal>sign</goal><br />
</goals><br />
'''<configuration>'''<br />
'''<gpgArguments>'''<br />
'''<arg>--pinentry-mode</arg>'''<br />
'''<arg>loopback</arg>'''<br />
'''</gpgArguments>'''<br />
'''</configuration>'''<br />
</execution><br />
</executions><br />
</plugin><br />
|<br />
|}<br />
<br />
==== Required steps for a pipeline job ====<br />
This is a simple pipeline job, that allows to test the GPG signing.<br />
<br />
{{Note|Note| Please note, the following script '''only''' works on the new infra (Jiro!). It does not work on CJE (jenkins.eclipse.org). Instructions for CJE can be found here: [[EE4J_Build]].}}<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent any<br />
tools {<br />
maven 'apache-maven-latest'<br />
jdk 'adoptopenjdk-hotspot-jdk8-latest'<br />
}<br />
stages {<br />
stage('Build') {<br />
steps {<br />
sh "mvn -B -U archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false"<br />
sh '''cat >my-app/pom.xml <<EOL<br />
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br />
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"><br />
<modelVersion>4.0.0</modelVersion><br />
<groupId>com.mycompany.app</groupId><br />
<artifactId>my-app</artifactId><br />
<packaging>jar</packaging><br />
<version>1.0-SNAPSHOT</version><br />
<name>my-app</name><br />
<url>http://maven.apache.org</url><br />
<dependencies><br />
<dependency><br />
<groupId>junit</groupId><br />
<artifactId>junit</artifactId><br />
<version>3.8.1</version><br />
<scope>test</scope><br />
</dependency><br />
</dependencies><br />
<build><br />
<plugins><br />
<plugin><br />
<groupId>org.apache.maven.plugins</groupId><br />
<artifactId>maven-gpg-plugin</artifactId><br />
<version>1.6</version><br />
<executions><br />
<execution><br />
<id>sign-artifacts</id><br />
<phase>verify</phase><br />
<goals><br />
<goal>sign</goal><br />
</goals><br />
<configuration><br />
<gpgArguments><br />
<arg>--pinentry-mode</arg><br />
<arg>loopback</arg><br />
</gpgArguments><br />
</configuration><br />
</execution><br />
</executions><br />
</plugin><br />
</plugins><br />
</build><br />
</project><br />
EOL'''<br />
withCredentials([file(credentialsId: 'secret-subkeys.asc', variable: 'KEYRING')]) {<br />
sh 'gpg --batch --import "${KEYRING}"'<br />
sh 'for fpr in $(gpg --list-keys --with-colons | awk -F: \'/fpr:/ {print $10}\' | sort -u); do echo -e "5\ny\n" | gpg --batch --command-fd 0 --expert --edit-key ${fpr} trust; done'<br />
sh "mvn -B -f my-app/pom.xml clean verify"<br />
}<br />
sh 'gpg --verify my-app/target/my-app-1.0-SNAPSHOT.jar.asc'<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
==== Custom container on Jiro ====<br />
When you are using a custom container on Jiro, you will need to add the settings-xml and settings-security-xml volume, like shown below.<br />
<br />
'''Please note:'''<br />
* the m2-repo volume is required as well, otherwise /home/jenkins/.m2/repository is not writable<br />
* the toolchains-xml volume is optional, but added for completeness<br />
* you also might need to add additional volumes like volume-known-hosts (as described here: https://wiki.eclipse.org/Jenkins#How_do_I_deploy_artifacts_to_download.eclipse.org.3F)<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: maven<br />
image: maven:alpine<br />
tty: true<br />
command:<br />
- cat<br />
volumeMounts:<br />
- name: settings-xml<br />
mountPath: /home/jenkins/.m2/settings.xml<br />
subPath: settings.xml<br />
readOnly: true<br />
- name: toolchains-xml<br />
mountPath: /home/jenkins/.m2/toolchains.xml<br />
subPath: toolchains.xml<br />
readOnly: true<br />
- name: settings-security-xml<br />
mountPath: /home/jenkins/.m2/settings-security.xml<br />
subPath: settings-security.xml<br />
readOnly: true<br />
- name: m2-repo<br />
mountPath: /home/jenkins/.m2/repository<br />
volumes:<br />
- name: settings-xml<br />
secret:<br />
secretName: m2-secret-dir<br />
items:<br />
- key: settings.xml<br />
path: settings.xml<br />
- name: toolchains-xml<br />
configMap:<br />
name: m2-dir<br />
items:<br />
- key: toolchains.xml<br />
path: toolchains.xml<br />
- name: settings-security-xml<br />
secret:<br />
secretName: m2-secret-dir<br />
items:<br />
- key: settings-security.xml<br />
path: settings-security.xml<br />
- name: m2-repo<br />
emptyDir: {}<br />
"""<br />
}<br />
}<br />
stages {<br />
stage('Run maven') {<br />
steps {<br />
container('maven') {<br />
sh 'mvn -version'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
=== How do I use /opt/tools in a custom container? ===<br />
<br />
You need to specify the tools persistence volume.<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
agent {<br />
kubernetes {<br />
label 'my-agent-pod'<br />
yaml """<br />
apiVersion: v1<br />
kind: Pod<br />
spec:<br />
containers:<br />
- name: custom-name<br />
image: my-custom-image:latest<br />
tty: true<br />
command:<br />
- cat<br />
volumeMounts:<br />
- name: tools<br />
mountPath: /opt/tools<br />
volumes:<br />
- name: tools<br />
persistentVolumeClaim:<br />
claimName: tools-claim<br />
"""<br />
}<br />
}<br />
stages {<br />
stage('Run maven') {<br />
steps {<br />
container('custom-name') {<br />
sh '/opt/tools/apache-maven/latest/bin/mvn -version'<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
{{important|Tools claim|On CJE (jenkins.eclipse.org) the claimName of the persistentVolumeClaim is "tools-claim", on Jiro the claimName is <code>tools-claim-jiro-<project_shortname></code> (e.g. <code>tools-claim-jiro-cbi</code> for the CBI project).}}<br />
<br />
=== Can projects get admin access on their Jiro JIPP? ===<br />
<br />
In general, we want to avoid handing out admin rights in the future. At the same time, - in the spirit of configuration as code - we are planning to allow projects to submit pull requests to our Jiro repo and change the configuration of their CI instance. E.g. adding plugins, etc. This will allow better tracking of configuration changes and rollback in case of issues.<br />
<br />
We understand that some projects heavily rely on their admin permissions. We will make sure to find an amicable solution in those cases.<br />
<br />
=== How can a new plugin be added to a Jiro JIPP? ===<br />
<br />
The preferred way is to open a pull request in the Jiro GitHub repo. For example, to add a new plugin to the CBI instance, one would need to edit https://github.com/eclipse-cbi/jiro/blob/master/instances/technology.cbi/jenkins/plugins-list and add the ID of the plugin. If the file <code>../instances/<project_name>/jenkins/plugins-list</code> does not exist yet, it needs to be created first.<br />
<br />
Only additional plugins that are not listed in https://wiki.eclipse.org/Jenkins#Default_plugins_-_Jiro_.28ci-staging.eclipse.org.2Fxxx_and_ci.eclipse.org.2Fxxx.29 need to be added to the plugins-list file.<br />
<br />
The ID of a Jenkins plugin can be found here: https://plugins.jenkins.io/<br />
<br />
If this sounds to complicated, you can also [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins&short_desc=Add%20plugin%20to%20JIPP%20of%20project%20NAME_OF_THE_PROJECT open a bug] on Bugzilla.<br />
<br />
== About resource packs and quotas ==<br />
<br />
The new infrastructure offers us the ability to prevent one of the major drawback of the old one: resource starvation. On the old infrastructure, one project could eat up all the resources of the machine and starve others, resulting in unpredictable build times, machine instabilities and unfairness. As such, we've defined resource quotas on the clustered infrastructure so that all projects get a fair share of resources.<br />
<br />
=== What's a resource pack? ===<br />
<br />
A resource pack is the indivisible base unit of compute cycles and memory (vCPU/RAM) that we allocate to projects for build jobs. All of them combined makes a pool of resources (its '''quota''') available to a project to run builds at any given time. More information about how many resource packs a project can get can be found on the [[CBI#Additional_Resource_Packs|CBI wiki page]].<br />
<br />
=== What about running build jobs concurrently? === <br />
<br />
First, a bit of Jenkins terminology (see [https://jenkins.io/doc/book/glossary/ Jenkins Glossary] for more details):<br />
<br />
* The '''master''' is the central, coordinating process which stores configuration, loads plugins, and renders the various user interfaces for Jenkins.<br />
* An '''agent''' (formerly called slave) is typically a (virtual) machine, or container, which connects to a Jenkins master and executes tasks when directed by the master. There are 2 kind of agents: dynamic and static. Dynamic agents are created on-demand when a build job require one. All agents on the clustered infrastructure are dynamic. Both dynamic and static agents can exists on the same master. <br />
* An '''executor''' is a slot for executing a build job defined by a pipeline or a job on an agent. An agent may have zero or more executors configured which corresponds to how many concurrent projects or pipelines are able to execute on that agent. '''All dynamic agents in the cluster have a single executor'''. Note that Jenkins masters can also have executors, but this is considered a bad practice for a long time and masters have no executors in the clustered infrastructure.<br />
<br />
<br />
By default, all Eclipse projects runs with a master able to dynamically create 2 agents in the cluster at the same time. Each of them of a single executor, meaning that projects can run 2 jobs at the same time. The resources required by both agents must be less or equal to the resource quota assigned to the project.<br />
<br />
=== What is the relationship between resource quota and concurrency level? ===<br />
<br />
We set the concurrency level on the cluster (i.e. the number of dynamic agents that can exist simultaneously in the cluster) to a number that depends on the resource quota your project get. We set it to a value equals to the number of vCPU you get. We don't think it's desirable to run a build job with less than 1 vCPU.<br />
<br />
=== How do I decide how much resources a build job will get to run? ===<br />
<br />
For freestyle jobs, you can't configure it. You must stick to what we've configured: freestyle jobs get 1vCPU (burst to 2vCPU) and 4GB of RAM. It is aligned with the default concurrency level we set for all (non-sponsored) projects and the resources they get.<br />
<br />
If projects want to customize the resources for a build job, projects need to use a [https://jenkins.io/doc/book/pipeline/ Jenkins pipeline]. See the [[Jenkins#What_is_killing_my_build.3F_I.27m_using_custom_containers.21|section above]] to learn how to do that.<br />
<br />
=== What does CPU burst means? ===<br />
<br />
When a build is scheduled, a new Jenkins agent is dynamically created in the cluster. The agent is scheduled on a physical node by Kubernetes (See [https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/ Kubernetes compute resource management documentation] for details). In general, Kubernetes tries to allocate agents on the least busy node. Once an agent is created on a node, it won't move until the end of the build. During the build, if there are some spare CPU cycles (i.e. cycles that have not been reserved by others) on the node, the agent will get more CPU up to the burst limit. So, while projects don't compete with each other for the requested vCPU, they compete for the CPU burst. Note that the burst should be shared fairly between projects. Globally it means that the availability of the upper limit of the burst mode depends on the global load of the cluster.<br />
<br />
=== What's the priority: the resource quota or the concurrency limit? ===<br />
<br />
The resource quota is the limiting factor. Concurrency limit is an upper bound. Let's take a project that has 2 resource packs (1 "free" + 1 "sponsored") as an example. It currently means that it has 4vCPU and 16GB or RAM to run its builds and has a concurrency limit of 4. It can configure its build jobs in several ways:<br />
<br />
* configure them all to use 2vCPU and 8GB of RAM. It means that only 2 of them can run at the same time. <br />
* configure them all to use 1vCPU and 4GB of RAM. Then 4 jobs can run concurrently. <br />
* configure them all but one to use 1vCPU/4GB RAM, the last one being a resource hog configured with 3vCPU and 12GB RAM. When small jobs are running, 4 of them run can concurrently, but when the resource hog runs, there is only enough resources left for 1 smaller build job.<br />
* configure them all to use 0.5vCPU and 2GB of RAM. Still, only 4 jobs can run simultaneously because the concurrency limit is 4.<br />
<br />
<br />
Note that burst resources (a.k.a. cpu limit in Kubernetes words) has to be treated the same way. It needs to be shared between jobs.<br />
<br />
=== Can I connect static agent to the Jenkins instance of my project? Does it count for the concurrency limit? ===<br />
<br />
Yes, projects can add as many external static agents as they want. Agents of this kind only need to have a SSH port open to the internet. Also, it does not count for the concurrency limit (as this is specific to the dynamically provisioned agents in the cluster).<br />
<br />
=== Do you do overbooking? ===<br />
<br />
Of course we do. CI jobs are something that fit very well with overbooking: not everybody need all their resources 100% of the time. Note that our goal is to size the cluster so that it can handle peak times though. So the wait time should be minimal.<br />
<br />
= Jenkins configuration and tools (bare-metal infra) =<br />
<br />
Check [[CI best practices]] for general recommendations how to setup Jenkins.<br />
<br />
== Tools (and locations) ==<br />
Build tools like JDK, Maven, Ant and Gradle are already configured in every Jenkins instance. <br />
<br />
* JDK<br />
<br />
Tools labeled ''jdk'' are Oracle JDK licensed under the [https://www.oracle.com/technetwork/java/javase/terms/license/index.html Oracle Binary Code License (BCL) for Java SE]. Tools labeled ''openjdk'' are Oracle builds of OpenJDK under the [http://openjdk.java.net/legal/gplv2+ce.html GPL+CE license]. Starting with JDK 11, the Eclipse Foundation won't provide any version of the JDK from Oracle licensed under the -commercial- Oracle Technology Network (OTN) terms. See [[#OpenJDK|OpenJDK]] and [[#Oracle|Oracle JDK]] sections above to learn more.<br />
<br />
** openjdk-jdk12-latest (/shared/common/java/openjdk/jdk-12_x64-latest)<br />
** openjdk-jdk11-latest (/shared/common/java/openjdk/jdk-11_x64-latest)<br />
** jdk10-latest (/shared/common/java/oracle/jdk-10_x64-latest)<br />
** jdk9-latest (/shared/common/jdk-9_x64-latest)<br />
** jdk1.8.0-latest (/shared/common/jdk1.8.0_x64-latest) <br />
** jdk1.7.0-latest (/shared/common/jdk1.7.0-latest) <br />
** jdk1.6.0-latest (/shared/common/jdk1.6.0-latest) <br />
** jdk1.5.0-latest (/shared/common/jdk1.5.0-latest) <br />
<br />
* Maven<br />
** apache-maven-latest (/shared/common/apache-maven-latest)<br />
** apache-maven-3.0.5 (/shared/common/apache-maven-3.0.5)<br />
<br />
* Ant<br />
** apache-ant-1.9.6 (/shared/common/apache-ant-1.9.6) <br />
<br />
* Gradle<br />
** gradle-latest (/shared/common/gradle-latest)<br />
** gradle-3.1 (/shared/common/gradle-3.1)<br />
<br />
More generally, all tools listed on http://build.eclipse.org/common/ are available from '''/shared/common/'''.<br />
<br />
If you need tools that are not general purpose installed, project members can install them in your project's home directory, for example ~/buildtools. [https://dev.eclipse.org/mhonarc/lists/cbi-dev/msg01869.html See email on cbi-dev]<br />
<br />
== Default plugins ==<br />
<br />
The following plugins are installed by default. Additional plugins can be installed on request.<br />
<br />
<div style="column-count:4;-moz-column-count:4;-webkit-column-count:4"><br />
* ace-editor<br />
* analysis-core<br />
* ant<br />
* antisamy-markup-formatter<br />
* authentication-tokens<br />
* bouncycastle-api<br />
* branch-api<br />
* build-timeout<br />
* cloudbees-folder<br />
* conditional-buildstep<br />
* credentials<br />
* credentials-binding<br />
* dashboard-view<br />
* disk-usage<br />
* display-url-api<br />
* docker-commons<br />
* docker-workflow<br />
* durable-task<br />
* external-monitor-job<br />
* extra-columns<br />
* find-bugs<br />
* gerrit-trigger<br />
* git<br />
* git-client<br />
* git-parameter<br />
* git-server<br />
* gradle<br />
* greenballs<br />
* handlebars<br />
* icon-shim<br />
* javadoc<br />
* jobConfigHistory<br />
* jquery<br />
* jquery-detached<br />
* junit<br />
* ldap<br />
* mailer<br />
* matrix-auth<br />
* matrix-project<br />
* maven-plugin<br />
* momentjs<br />
* pam-auth<br />
* parameterized-trigger<br />
* pipeline-build-step<br />
* pipeline-graph-analysis<br />
* pipeline-input-step<br />
* pipeline-milestone-step<br />
* pipeline-model-api<br />
* pipeline-model-declarative-agent<br />
* pipeline-model-definition<br />
* pipeline-model-extensions<br />
* pipeline-rest-api<br />
* pipeline-stage-step<br />
* pipeline-stage-tags-metadata<br />
* pipeline-stage-view<br />
* plain-credentials<br />
* promoted-builds<br />
* rebuild<br />
* resource-disposer<br />
* scm-api<br />
* script-security<br />
* sonar<br />
* ssh-credentials<br />
* ssh-slaves<br />
* structs<br />
* timestamper<br />
* token-macro<br />
* windows-slaves<br />
* workflow-aggregator<br />
* workflow-api<br />
* workflow-basic-steps<br />
* workflow-cps<br />
* workflow-cps-global-lib<br />
* workflow-durable-task-step<br />
* workflow-job<br />
* workflow-multibranch<br />
* workflow-scm-step<br />
* workflow-step-api<br />
* workflow-support<br />
* ws-cleanup<br />
* xvnc<br />
</div><br />
<br />
== Setup for specific plugins ==<br />
<br />
=== GitHub Pull Request Builder Plugin ===<br />
<br />
The [https://wiki.jenkins.io/display/JENKINS/GitHub+pull+request+builder+plugin GitHub Pull Request Builder Plugin] (GHPRB) allows to build/test pull requests and provide immediate feedback in the pull request on GitHub.<br />
<br />
'''To set this up, please open a Bugzilla issue against the CI-Jenkins component (Product: Community) and request this feature.'''<br />
<br />
Here are some details about what happens during the setup process:<br />
* The GHPRB plugin is installed in the JIPP.<br />
* Webmaster creates a GitHub bot user and adds it to the respective team on GitHub.<br />
* The credentials of the GitHub bot user are added to the JIPP (with user name and password, because SSH keys are not recommended/supported by the plugin).<br />
* The GHPRB plugin's main config is set up.<br />
<br />
Once the ticket is resolved you should be able to configure and use the GHPRB plugin in your jobs.<br />
<br />
Instructions how to set up GHPRB plugin in jobs can be found here:<br />
https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md<br />
<br />
'''Please note: ''' the 'Use github hooks for build triggering' option has to be disabled, since it requires admin permissions for the GitHub bot user, which we don't allow. With this option turned off, Jenkins is polling GitHub instead. Which should work just fine in most cases.<br />
<br />
More info can be found in the GitHub readme:<br />
https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md<br />
<br />
=== Jenkins Pipeline (aka configuration in code) ===<br />
<br />
An example how Eclipse plugins can be build with Tycho using a Jenkins pipeline can be found here (Thanks to Mickael Istria!):<br/><br />
https://github.com/eclipse/aCute/blob/master/Jenkinsfile<br />
<br />
More info about Jenkins Pipeline can be found here:<br/><br />
https://jenkins.io/doc/book/pipeline/<br/><br />
https://jenkins.io/doc/book/pipeline/shared-libraries/<br />
<br />
=== Gerrit Trigger Plugin ===<br />
<br />
You may use the [https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger Jenkins Gerrit Trigger Plugin] in order to run a Jenkins job to verify each new patchset uploaded to Gerrit for code review. Jenkins (named "CI Bot") will then also vote on these changes using the "Verify" voting category.<br />
<br />
[[Image:Jgit.gerrit-reviewer.png|450px]]<br />
<br />
[[Image:Jgit.gerrit-vote.png|450px]]<br />
<br />
Below, the configuration sections for the Git plugin and the Gerrit trigger plugin of the verification job used by the EGit project may serve as an example.<br />
<br />
====General configuration settings====<br />
<br />
# Check ''This project is parameterized''. Click the ''Add'' button and select ''String Parameter''. Set the parameter ''Name'' to '''GERRIT_REFSPEC''' and ''Default Value'' to '''refs/heads/master'''.<br />
<br />
[[Image:Gerrit-refspec-param.png|600px]]<br />
<br />
====Configuration of Source Code Management====<br />
<br />
# Under ''Source Code Management'' select Git. <br />
<br />
# Under ''Repositories'', click on ''Advanced'' and change the '''Refspec''' to '''${GERRIT_REFSPEC}'''.<br />
<br />
# Under ''Additional Behaviours'', add '''Strategy for choosing what to build''' and select '''Gerrit Trigger''' as a strategy. <br />
<br />
[[Image:Jgit.gerrit-git-config.png|600px]]<br />
<br />
Note that the section '''Branches to build''' won't be used and may be deleted.<br />
<br />
====Configuration of Build Triggers ====<br />
<br />
# Under ''Build Triggers'', select '''Gerrit event'''. <br />
<br />
[[Image:Jgit.gerrit-gerrit-config.png|600px]]<br />
<br />
# Under ''Trigger on'', click on ''Add'' and select at least '''Patchset Created'''. This will configure the job to run on each new patchset. You can also add additional trigger, like '''Comment Added Contains Regular Expression'''. In the example below, a build will be triggered for the latest patch set if the comment is exactly '''CI Bot, run a build please'''.<br />
<br />
[[Image:gerrit-trigger-events.png|600px]]<br />
<br />
# Finally, configure at least one ''Gerrit Project''. The pattern is the name of project (i.e. if your repository is <code>git.eclipse.org/<xx>/<yy>.git</code>, then fill the pattern <code>xx/yy</code>). The ''Branches'' section is the list of branch to listen for events as configured above. Generally, you want one, named '''master''' to build patches submitted for the master branche, or <code>**</code> to build patches submitted to each and every branches. Set the type to '''Path'''.<br />
<br />
[[Image:gerrit-trigger-project.png|600px]]<br />
<br />
====Configuration of the build action====<br />
<br />
Under "Build" click the "Add a build step" button, and select the appropriate action. The actual action depends on what you want Hudson to do. A typical example, for projects build with Maven is to select "Invoke Maven 3" and set "Maven 3" to "apache-maven-latest" and "Goals" to "clean verify".<br />
<br />
== Howto ==<br />
<br />
=== How to build my project's website with Jenkins? ===<br />
<br />
The preferred static website generator for build Eclipse project websites is [https://gohugo.io Hugo]. You should first put your Hugo sources in a dedicated Git repository, either at GitHub if your source code is already hosted at GitHub or at git.eclipse.org. If you don't have such a repository already, feel free to [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Git open a request], the Eclipse IT team will create one for you. <br />
<br />
Note that each and every Eclipse project automatically gets a Git repository with <code>git.eclipse.org/www.eclipse.org/<project_name></code> (see this [https://git.eclipse.org/r/plugins/gitiles/www.eclipse.org/ repository index] for complete list). This is not where you want to push your Hugo sources. This repository contains the webpages that are automatically and regularly pulled and published on the www.eclipse.org HTTP server. All the content from the master branch will eventually be available at the URL '''<nowiki>https://www.eclipse.org/<project_name/></nowiki>'''. <br />
<br />
Once your Hugo sources are in the proper repository, create a file named <code>Jenkinsfile</code> at the root of the repository with the following content ('''don't forget to specify the proper value for <code>PROJECT_NAME</code> and <code>PROJECT_BOT_NAME</code> environment variable'''):<br />
<br />
<source lang="groovy" style="border:1px solid;padding: 5px; margin: 5px;"><br />
pipeline {<br />
<br />
agent {<br />
kubernetes {<br />
label 'hugo-agent'<br />
yaml """<br />
apiVersion: v1<br />
metadata:<br />
labels:<br />
run: hugo<br />
name: hugo-pod<br />
spec:<br />
containers:<br />
- name: jnlp<br />
volumeMounts:<br />
- mountPath: /home/jenkins/.ssh<br />
name: volume-known-hosts<br />
- name: hugo<br />
image: eclipsecbi/hugo:0.42.1<br />
command:<br />
- cat<br />
tty: true<br />
volumes:<br />
- configMap:<br />
name: known-hosts<br />
name: volume-known-hosts<br />
"""<br />
}<br />
}<br />
<br />
environment {<br />
PROJECT_NAME = "<project_name>" // must be all lowercase.<br />
PROJECT_BOT_NAME = "<Project_name> Bot" // Capitalize the name<br />
}<br />
<br />
triggers { pollSCM('H/10 * * * *') <br />
<br />
}<br />
<br />
options {<br />
buildDiscarder(logRotator(numToKeepStr: '5'))<br />
checkoutToSubdirectory('hugo')<br />
}<br />
<br />
stages {<br />
stage('Checkout www repo') {<br />
steps {<br />
dir('www') {<br />
sshagent(['git.eclipse.org-bot-ssh']) {<br />
sh '''<br />
git clone ssh://genie.${PROJECT_NAME}@git.eclipse.org:29418/www.eclipse.org/${PROJECT_NAME}.git .<br />
git checkout ${BRANCH_NAME}<br />
'''<br />
}<br />
}<br />
}<br />
}<br />
stage('Build website (master) with Hugo') {<br />
when {<br />
branch 'master'<br />
}<br />
steps {<br />
container('hugo') {<br />
dir('hugo') {<br />
sh 'hugo -b https://www.eclipse.org/${PROJECT_NAME}/'<br />
}<br />
}<br />
}<br />
}<br />
stage('Build website (staging) with Hugo') {<br />
when {<br />
branch 'staging'<br />
}<br />
steps {<br />
container('hugo') {<br />
dir('hugo') {<br />
sh 'hugo -b https://staging.eclipse.org/${PROJECT_NAME}/'<br />
}<br />
}<br />
}<br />
}<br />
stage('Push to $env.BRANCH_NAME branch') {<br />
when {<br />
anyOf {<br />
branch "master"<br />
branch "staging"<br />
}<br />
}<br />
steps {<br />
sh 'rm -rf www/* && cp -Rvf hugo/public/* www/'<br />
dir('www') {<br />
sshagent(['git.eclipse.org-bot-ssh']) {<br />
sh '''<br />
git add -A<br />
if ! git diff --cached --exit-code; then<br />
echo "Changes have been detected, publishing to repo 'www.eclipse.org/${PROJECT_NAME}'"<br />
git config --global user.email "${PROJECT_NAME}-bot@eclipse.org"<br />
git config --global user.name "${PROJECT_BOT_NAME}"<br />
git commit -m "Website build ${JOB_NAME}-${BUILD_NUMBER}"<br />
git log --graph --abbrev-commit --date=relative -n 5<br />
git push origin HEAD:${BRANCH_NAME}<br />
else<br />
echo "No change have been detected since last build, nothing to publish"<br />
fi<br />
'''<br />
}<br />
}<br />
}<br />
}<br />
}<br />
}<br />
</source><br />
<br />
<br />
Finally, you can create a multibranch pipeline job on your project's Jenkins instance. It will automatically be triggered on every new push to your Hugo source repository, build the website and push it to the <code>git.eclipse.org/www.eclipse.org/<project_name>.git</code> repository. As mentioned above, the Eclipse Foundation website's infrastructure will eventually pull the content of the latter and your website will be published and available on '''<nowiki>http://www.eclipse.org/<project_name></nowiki>'''.<br />
<br />
If you don't have a Jenkins instance already, [[CBI#Requesting_a_JIPP_instance|ask for one]]. If you need assistance with the process, [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins open a ticket].<br />
<br />
=== How to connect a JIPP to an external slave? ===<br />
<br />
The Jenkins (JIPP) instances hosted by the Eclipse Foundation are located on a private, non-routable network that can only establish HTTP/S connections to the Internet. To connect your JIPP to an external slave, you'll need to perform some SSH wizardry:<br />
<br />
===== *NIX and SSH slaves =====<br />
<br />
* On your JIPP, create a job that will only run this shell script once. Edit as required.<br />
<br />
<source lang="bash" style="border:1px solid;padding: 5px; margin: 5px;"><br />
ssh-keygen -t rsa -b 4096 -C "CBI genie" -f ~/.ssh/id_rsa.cbi -N ""<br />
chmod 600 ~/.ssh/id_rsa.cbi.pub<br />
echo "Adding pub key to authorized_keys file to log into build.eclipse.org"<br />
cat ~/.ssh/id_rsa.cbi.pub >> ~/.ssh/authorized_keys<br />
echo "Copy this key to your remote server's ~/.ssh/authorized_keys file"<br />
cat ~/.ssh/id_rsa.cbi.pub<br />
echo "Creating config"<br />
echo "" >> ~/.ssh/config<br />
echo "Host build.eclipse.org" >> ~/.ssh/config<br />
echo "StrictHostKeyChecking no" >> ~/.ssh/config<br />
echo "Host external-slave" >> ~/.ssh/config<br />
echo "StrictHostKeyChecking no" >> ~/.ssh/config<br />
echo "IdentityFile ~/.ssh/id_rsa.cbi" >> ~/.ssh/config<br />
echo "PubkeyAuthentication yes" >> ~/.ssh/config<br />
echo "ServerAliveInterval 60" >> ~/.ssh/config<br />
echo "ProxyCommand ssh -o StrictHostKeyChecking=no -i ~/.ssh/id_rsa.cbi build.eclipse.org netcat %h 22" >> ~/.ssh/config<br />
chmod 600 ~/.ssh/config<br />
echo <br />
echo "Finished setting up SSH config"<br />
cat ~/.ssh/config<br />
</source><br />
<br />
* Copy the public key that appears in the console to the authorized_keys file of the remote server, as instructed.<br />
* In Jenkins' management, create a new slave node. Choose the option to "Launch slave via execution of command on Master". If you don't have administration rights on your JIPP, please [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=CI-Jenkins open a ticket].<br />
<br />
* Use this command, replacing (projectname) with the name of your project and username with the external username. Sadly, I cannot get bash ~ or $HOME here. If you want to make sure the slave jar is always the same version as the slave, make sure you use the slave jar available from your JIPP instance.<br />
<br />
<source lang="bash" style="border:1px solid;padding: 5px; margin: 5px;"><br />
ssh -C -i /opt/public/hipp/homes/genie.(projectname)/.ssh/id_rsa.cbi username@external-slave "wget -qO slave.jar https://ci.eclipse.org/cbi/jnlpJars/slave.jar ; java -jar slave.jar"<br />
</source><br />
<br />
===== Windows via jnlp =====<br />
<br />
To be determined, see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=490701 bug 490701]. SSH also works if OpenSSH/Cygwin is installed on the Windows host.<br />
<br />
= HIPP to JIPP migration (HIPP2JIPP) = <br />
<br />
'''As of March 1st, 2018 all Hudson masters have been migrated to Jenkins.''' See https://ci.eclipse.org<br />
<br />
* The following tool was used to convert the configuration XMLs to a format that Jenkins understands: https://github.com/eclipse/hipp2jipp <br />
* Some know issues are listed here: https://github.com/eclipse/hipp2jipp#known-issues<br />
* Also some custom scripts (specific to the Eclipse Foundation's build infrastructure) have been used.<br />
* In most cases the migration worked straight-forward and configurations were converted without any problems. Backups were created and can be made available on request if configurations are lost.<br />
<br />
= Cluster migration =<br />
<br />
See [[CBI/Jenkins_Migration_FAQ]]<br />
<br />
= Build performance optimization =<br />
=== Use Tycho 1.4+ ===<br />
Tycho 1.4 calculates bundle timestamps from the git history much faster than the versions before (you may see improvements of some seconds per Maven aggregator module). Besides that, also all your other tools (Maven, Maven Plugin, JDK, ...) should be on the most recent level possible with the target environment restrictions of your project.<br />
=== Disable unnecessary gerrit triggers ===<br />
Check at least "draft" and "private" in the gerrit trigger section for changes to be excluded from automatic builds.<br />
=== Avoid ** in Ant globs ===<br />
When archiving artifacts, scanning for test reports and so on, avoid using double asterisk wildcard for "any directory". That can take a huge amount of time. In almost all cases we can easily specify the path with single wildcard, like */target/report/*.xml<br />
=== Maven batch mode ===<br />
Always run maven with --batch-mode to get rid of the many lines of download progress in the console. Will avoid several MB of log output with each build, making it easier for you to diagnose builds and easier for Jenkins to store them.<br />
=== Parallel Tycho build ===<br />
Tycho plugins are not marked thread-safe. Nevertheless many projects use [https://cwiki.apache.org/confluence/display/MAVEN/Parallel+builds+in+Maven+3 parallel Maven builds] with Tycho without problems. If you take this route, make sure that only one UI test can run at any given time (e.g. there is only a single executor on the same node). If you feel confident after a while, you may even want to disable the non-thread-safe warnings using -Dorg.slf4j.simpleLogger.log.org.apache.maven.lifecycle.internal.builder.BuilderCommon=error.<br />
=== Reuse the working directory ===<br />
On nodes that are re-used for multiple builds, do not delete the Jenkins workspace at the start/end of the build. Otherwise you have to clone the repository again on next build. It's faster to use git reset -fdx instead.<br />
=== Disable secondary artifacts in gerrit builds ===<br />
Your build may create documentation, online help, source features, sign artifacts and many other things in addition to compilation and test. Use Maven profiles to disable most of those additional build steps for gerrit builds. Only build those on the master branch after merging the gerrit change. Of course there is a trade-off here between how often your master branch may break and how much time you can save in gerrit builds.<br />
=== Eliminate slow tests ===<br />
From a green build, open the test results tab. Click the table header to sort by execution time. Starting from the top look for rows with a little number of contained test methods. Optimize/delete these tests, they are eating too much time per test case.<br />
=== Pipeline durability hints ===<br />
If you configure jobs via pipeline, you probably want to [https://jenkins.io/doc/book/pipeline/scaling-pipeline/ configure them for performance instead of durability].<br />
<br />
[[Category:Releng]] [[Category:Jenkins]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.5&diff=433768EGit/New and Noteworthy/5.52019-08-15T19:56:17Z<p>Michael.keppler.gmx.de: tree presentation option in staging view</p>
<hr />
<div>= EGit =<br />
<br />
== Creating Lightweight Tags ==<br />
<br />
With EGit 5.5, you can create lightweight tags. Just leave the message field in the "Create Tag" dialog empty:<br />
<br />
[[File:Create Lightweight Tag.png|alt=Screenshot of the "Create Tag" dialog showing the tooltip on the "Create" button explaining this.]]<br />
<br />
A lightweight tag doesn't store any author information (who created the tag) or message, and it cannot be signed. It is really just a plain name for a commit. An annotated commit, on the other hand, additionally stores a message, and also the author of the tag.<br />
<br />
If an existing tag is selected and the "Force replace existing tag" option is checked, the dialog can also be used to move a tag (make it refer to a different commit than before), or to change an annotated tag into a lightweight tag (by clearing the message) or vice versa (by adding a message).<br />
<br />
== History option to show first parents only ==<br />
<br />
A history graph with many merges can be very hard to read. Therefore native git log has an option --first-parent, which shows only the first parent of each merge commit. This is now also available in the EGit history view.<br />
<br />
[[File:Egit-first-parent.png|alt=History with first parent only enabled]]<br />
<br />
Notice the many merge commits in the history, which all show only one parent, instead of splitting into more and more lines.<br />
<br />
== Renaming branches became easier ==<br />
<br />
Before EGit 5.5 you had to navigate to a branch node in the repository view, in order to rename the branch. Now you can use the F2 key for renaming a branch both on the branch node or on the repository node. No need to expand all the nodes down to the branch node anymore.<br />
<br />
== Staged files as list or tree ==<br />
<br />
EGit had an option to display the staged and unstaged files as a flat list or as a tree of folders and files since a long time already. Both can be very helpful when you want to stage only some of many changed files, either based on their name or based on their location. To make more users aware of the different presentations, the option can now be changed more easily via a dropdown menu next to the unstaged files area in the history view.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.5 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.5.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following X developers worked on this release:<br />
<br />
<TBD: list of contributors, number><br />
<br />
= Video =<br />
<br />
You can see many of the changes in action in the <TBD: insert video link, if there is a video> video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.5|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.5&diff=433767EGit/New and Noteworthy/5.52019-08-15T19:24:32Z<p>Michael.keppler.gmx.de: first parent only</p>
<hr />
<div>= EGit =<br />
<br />
== Creating Lightweight Tags ==<br />
<br />
With EGit 5.5, you can create lightweight tags. Just leave the message field in the "Create Tag" dialog empty:<br />
<br />
[[File:Create Lightweight Tag.png|alt=Screenshot of the "Create Tag" dialog showing the tooltip on the "Create" button explaining this.]]<br />
<br />
A lightweight tag doesn't store any author information (who created the tag) or message, and it cannot be signed. It is really just a plain name for a commit. An annotated commit, on the other hand, additionally stores a message, and also the author of the tag.<br />
<br />
If an existing tag is selected and the "Force replace existing tag" option is checked, the dialog can also be used to move a tag (make it refer to a different commit than before), or to change an annotated tag into a lightweight tag (by clearing the message) or vice versa (by adding a message).<br />
<br />
== History option to show first parents only ==<br />
<br />
A history graph with many merges can be very hard to read. Therefore native git log has an option --first-parent, which shows only the first parent of each merge commit. This is now also available in the EGit history view.<br />
<br />
[[File:Egit-first-parent.png|alt=History with first parent only enabled]]<br />
<br />
Notice the many merge commits in the history, which all show only one parent, instead of splitting into more and more lines.<br />
<br />
== Renaming branches became easier ==<br />
<br />
Before EGit 5.5 you had to navigate to a branch node in the repository view, in order to rename the branch. Now you can use the F2 key for renaming a branch both on the branch node or on the repository node. No need to expand all the nodes down to the branch node anymore.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.5.0 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.5.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following X developers worked on this release:<br />
<br />
<TBD: list of contributors, number><br />
<br />
= Video =<br />
<br />
You can see many of the changes in action in the <TBD: insert video link, if there is a video> video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.5|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=File:Egit-first-parent.png&diff=433766File:Egit-first-parent.png2019-08-15T19:20:34Z<p>Michael.keppler.gmx.de: </p>
<hr />
<div></div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.5&diff=433755EGit/New and Noteworthy/5.52019-08-15T06:47:11Z<p>Michael.keppler.gmx.de: </p>
<hr />
<div>= EGit =<br />
<br />
== Creating Lightweight Tags ==<br />
<br />
With EGit 5.5, you can create lightweight tags. Just leave the message field in the "Create Tag" dialog empty:<br />
<br />
[[File:Create Lightweight Tag.png|alt=Screenshot of the "Create Tag" dialog showing the tooltip on the "Create" button explaining this.]]<br />
<br />
A lightweight tag doesn't store any author information (who created the tag) or message, and it cannot be signed. It is really just a plain name for a commit. An annotated commit, on the other hand, additionally stores a message, and also the author of the tag.<br />
<br />
If an existing tag is selected and the "Force replace existing tag" option is checked, the dialog can also be used to move a tag (make it refer to a different commit than before), or to change an annotated tag into a lightweight tag (by clearing the message) or vice versa (by adding a message).<br />
<br />
== Renaming branches became easier ==<br />
<br />
Before EGit 5.5 you had to navigate to a branch node in the repository view, in order to rename the branch. Now you can use the F2 key for renaming a branch both on the branch node or on the repository node. No need to expand all the nodes down to the branch node anymore.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.5.0 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.5.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following X developers worked on this release:<br />
<br />
<TBD: list of contributors, number><br />
<br />
= Video =<br />
<br />
You can see many of the changes in action in the <TBD: insert video link, if there is a video> video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.5|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.4&diff=432978EGit/New and Noteworthy/5.42019-06-20T05:46:45Z<p>Michael.keppler.gmx.de: add youtube video with changes of Eclipse 2019-06</p>
<hr />
<div>= EGit =<br />
<br />
== SSH Library ==<br />
<br />
EGit 5.4.0 can now handle ''encrypted'' new-style OpenSSH private keys, for instance password-protected ed25519 keys, when the "Apache MINA sshd" SSH client is used. (There's a preference setting in the main EGit preference page under ''Preferences&rarr;Team&rarr;Git'' to choose between "Apache MINA sshd" (default) and the older "JSch" library.)<br />
:On Java versions older than 8u161, you may need to download and install the [https://www.oracle.com/technetwork/java/javase/downloads/jce-all-download-5170447.html "JCE Unlimited Strength Jurisdiction Policy Files"] for this to work. OpenSSH uses the AES encryption with 256bit keys, which is available in older Java only with this extension. On newer Java versions, "unlimited strength" encryption is enabled by default, so you need not do anything.<br />
<br />
We plan to remove the old JSch SSH implementation completely in a future release of EGit.<br />
<br />
== Filtering Content from the Git Repositories View ==<br />
<br />
The Git Repositories view can now be configured to show less nodes.<br />
<br />
[[File:EGit_Repo_View_Filters.png|alt=Screenshot showing the "Filters and Customization..." entry in the view menu of the Git Repositories view]]<br />
<br />
In the view menu of the Git Repositories view, choose the "Filters and Customization..." entry. This will open a dialog where you can choose which information should be suppressed:<br />
<br />
[[File:EGit Repo View Filters Dialog.png|alt=Screenshot of the "Filters and Customization" dialog of the Git Repositories view]]<br />
<br />
Checked node types will ''not'' be shown in the Git Repositories view. Note that the top repositories nodes and the local branches node cannot be hidden.<br />
<br />
== Checking out Files from a Commit ==<br />
<br />
In the Git History view there is a new command in the context menu on the file list to check out the selected file versions from that commit. This can be useful to revert individual files to an earlier state, or to a state on another branch.<br />
<br />
[[File:Check Out This Version.png|alt=Screenshot of the Git History view showing the new check-out command.]]<br />
<br />
This command is also available in the Commit Viewer (also for stashes), and in the outline view of the Commit Viewer's unified diff page. The check-out skips files deleted in that commit and submodules contained in the selection. If the check-out would overwrite uncommitted changes, such as when a file to be checked out is modified in the workspace, the user is asked to confirm overwriting.<br />
<br />
== Showing Whitespace Characters in the Diff in the History View ==<br />
<br />
The diff viewer in the Git History view can now show whitespace characters:<br />
<br />
[[File:EGit History Whitespace.png|alt=Screenshot of the Git History view with the context menu on the diff viewer visible and showing whitespace characters in the diff viewer.]]<br />
<br />
The diff viewer is located in the bottom-left part of the view, below the commit message. When files changed in a commit are selected in the file list bottom-right, the diff viewer shows a unified diff of the changes made to those files in that commit. (For performance reasons, the diff is truncated after 10'000 lines; to see a full unified diff, open the commit in the Commit Viewer via the context menu in the commit table.)<br />
<br />
This diff viewer has now a little context menu where the user can enable or disable showing whitespace characters.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.4.0 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.4.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following 8 developers worked on this release:<br />
<br />
Alexander Nittka,<br />
Andrey Loskutov,<br />
Carsten Hammer,<br />
George Gastaldi,<br />
Matthias Sohn,<br />
Michael Keppler,<br />
Peter Severin,<br />
Thomas Wolf<br />
<br />
= Video =<br />
You can see many of the changes in action in the [https://www.youtube.com/embed/SYqFybeUbeI Eclipse 2019-06 IDE Improvements: General and Git] video.<br />
<br />
= See Also =<br />
<br />
See also the [[JGit/New_and_Noteworthy/5.4|new features in JGit]] for additional information.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/5.3&diff=431019EGit/New and Noteworthy/5.32019-03-08T14:03:53Z<p>Michael.keppler.gmx.de: requirements</p>
<hr />
<div>= EGit =<br />
<br />
== Requires Eclipse Neon ==<br />
<br />
EGit 5.3.0 requires Eclipse Neon (4.6) or better. If you use an older version of Eclipse, you are recommended to upgrade the complete Eclipse IDE.<br />
<br />
== GPG-signing Commits ==<br />
<br />
EGit 5.3.0 can sign commits with GPG.<br />
<br />
[[File:egit-commit-sign.png|alt=Screenshot of the EGit Staging View with the new "Sign commit" icon]]<br />
<br />
The new icon in the upper right will allow you to toggle commit signing on or off. The default is read from the Git configuration. If the config option <code>commit.gpgsign</code> is set to <code>true</code>, the button will be selected by default. The value of <code>user.signingkey</code> will be used to determine the signing key. If the value is unset, the email address of the committer will be used to lookup the key. If no key can be found a commit will fail.<br />
<br />
Keys will be looked up from your GPG keyring (either <code>~/.gnupg/pubring.kbx</code> or <code>~/.gnupg/secring.gpg</code>; on Windows the directory <code>%APPDATA%\gnupg</code> is used&mdash;if it exists&mdash;instead of <code>~/.gnupg</code>). <br />
<br />
See the following GitHub help pages for help on GPG signing keys:<br />
* [https://help.github.com/articles/generating-a-new-gpg-key/ Generating a new GPG key]<br />
* [https://help.github.com/articles/telling-git-about-your-signing-key/ Telling Git about your signing key]<br />
* [https://help.github.com/articles/associating-an-email-with-your-gpg-key/ Associating an email with your GPG key]<br />
<br />
== SSH Library ==<br />
<br />
In the last release we had introduced a new SSH client based on the [https://mina.apache.org/sshd-project/ Apache MINA sshd] library as an alternative to the JSch-based client. In EGit 5.3.0 the default settings are switched: by default, the Apache MINA implementation is used.<br />
<br />
<div style="display:none"><br />
TBD: With Egit 5.3.0 it is now also possible to use ''encrypted'' new-style OpenSSH private keys, for instance password-protected ed25519 keys.<br />
:On Java versions older than 8u161, you may need to download and install the "[https://www.oracle.com/technetwork/java/javase/downloads/jce-all-download-5170447.html JCE Unlimited Strength Jurisdiction Policy Files]" for this to work. OpenSSH uses the AES encryption with 256bit keys, which is available in older Java only with this extension. On newer Java versions, "unlimited strength" encryption is enabled by default, so you need not do anything.<br />
</div><br />
<br />
We plan to remove the old JSch SSH implementation completely in a future release of EGit.<br />
<br />
== Compare and Merge Editors ==<br />
<br />
Text comparisons in Eclipse have been improved to make "Show Whitespace" work in more cases.<br />
<br />
Also, concurrent editing of a file in a merge editor and in another editor open on the same file has been improved and works now better and even for files not in the Eclipse workspace.<br />
<br />
[[File:EGit Compare Editor Show Whitespace.png|alt=Screenshot of a Java comparison in Eclipse (workspace against index) showing whitespace on the index side]]<br />
<br />
Note that both showing whitespace and concurrent editing depend not only on the way EGit sets up the comparison (which is what we improved) but also on the actual editors being used. These editors are beyond the control of EGit. With files not in the Eclipse workspace, one may encounter Platform [https://bugs.eclipse.org/bugs/show_bug.cgi?id=214351 bug 214351] when a file is open in another editor.<br />
<br />
== Other Changes ==<br />
<br />
EGit 5.3.0 includes lots of less noticeable improvements in the UI, plus a number of bug fixes. We also made a number of performance improvements. The complete list of new features and bug fixes is available in the [https://projects.eclipse.org/projects/technology.egit/releases/5.3.0/ release notes].<br />
<br />
= Contributors =<br />
<br />
The following X developers worked on this release:<br />
<br />
<TBD: list of contributors, number></div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.4&diff=430935Tycho/Release Notes/1.42019-03-05T18:53:11Z<p>Michael.keppler.gmx.de: /* New and Noteworthy */</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.3|&lt; Previous Version]] | Next Version &gt;</div><br />
<br />
<br />
<br />
<br />
== SNAPSHOT builds ==<br />
<br />
<br />
<br />
Tycho 1.4.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.4.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://ci.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.4.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.4.0-SNAPSHOT]<br />
<br />
=== Objectweb ASM update ===<br />
<br />
ObjectWeb ASM has been updated to version 7.0 from 5.0.3 which provides Java 11 compatibility in artifactcomparator. '''Note:''' Due to upstream no longer producing org.ow2.asm:asm-debug-all Tycho now requires org.ow2.asm:asm-tree and org.ow2.asm:asm-util. {{bug|543850}}<br />
<br />
=== Resolving Java 11 removed modules ===<br />
<br />
Java 11 removed a number of modules which broke compilation/tests/resolving deps when the bundle has lower BREE as they were resolved from the BREE profile. Now Tycho will check if runtime Java is 11+ and if it differs from bundle's EE - in this case it will resolve deps with current runtime's EE. '''Note:''' Some additional bundles may need to be added to the target platform to replace the removed JDK modules. {{bug|541403}}<br />
<br />
=== Performance improvement ===<br />
<br />
If you have configured Tycho to create [[Tycho/Reproducible Version Qualifiers|reproducable version qualifiers]], then Tycho will calculate the qualifier from the underlying git history. This can take quite a while on git repositories with a big history. In Tycho 1.4 the history retrieval has been optimized, and we have seen the execution time drop down from several seconds to less than a second on a big repository. This calculation is done for each module in an aggregator. If you build big aggregators with many modules, then you may gain some minutes of build time just by upgrading Tycho. {{bug|544005}}<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.4]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.3&diff=429627Tycho/Release Notes/1.32018-12-07T09:15:15Z<p>Michael.keppler.gmx.de: add bugzilla link</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css> <br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.2|&lt; Previous Version]] | Next Version &gt;</div> <br />
<br />
== SNAPSHOT builds ==<br />
<br />
Tycho 1.3.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.3.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://ci.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.3.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.3.0-SNAPSHOT]<br />
<br />
<br />
=== Java 11 ===<br />
<br />
* JDT was updated to 3.15.1 (we are now using ecj binaries from maven central as opposed to jdt.core and jdt.compiler.apt) {{bug|532302}}<br />
<br />
<br />
=== org.apache.felix.scr ===<br />
<br />
<br />
{{bug|538729}}<br />
<br />
Tycho 1.3.0 surefire plugin supports starting applications that use org.apache.felix.scr bundle in place of org.eclipse.equinox.ds (like Eclipse Platform 4.10 based target-platforms)<br />
<br />
=== download.stats artifact metadata property ===<br />
<br />
{{bug|539552}}<br />
<br />
Support for <tt>download.stats</tt> property on artifacts metadata. In order to (partially) enable p2 download stats as documented in [[Equinox_p2_download_stats]], you can now configure you <tt>tycho-p2-plugin:p2-metadata</tt> [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/tycho-p2/tycho-p2-plugin/p2-metadata-mojo.html#generateDownloadStatsProperty generateDownloadStats parameter] to add the necessary property on the artifacts:<br />
<br />
<source lang="xml"><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-p2-plugin</groupId><br />
<configuration><br />
<generateDownloadStatsProperty>true</generateDownloadStatsProperty><br />
</configuration><br />
</plugin><br />
</source><br />
<br />
<br />
or alternatively, you can override the <tt>tycho.generateDownloadStatsProperty</tt> property either by CLI with <tt>mvn -Dtycho.generateDownloadStatsProperty=true ...</tt> or by adding <tt><tycho.generateDownloadStatsProperty>true</tycho.generateDownloadStatsProperty></tt> in the <tt><properties></tt> element of your pom.xml.<br />
<br />
This results in this in artifacts.xml (and derived artifacts.jar and artifacts.xml.xz):<br />
<source lang="xml"><br />
<artifacts size='4'><br />
<artifact classifier='osgi.bundle' id='bundle' version='1.0.0.123abc'><br />
<properties size='9'><br />
<!-- ... --><br />
<property name='download.stats' value='bundle/1.0.0.123abc'/><br />
<!-- ... --><br />
</properties><br />
</artifact><br />
<artifact classifier='osgi.bundle' id='bundle' version='1.0.0.123abc'><br />
<processing size='1'><br />
<step id='org.eclipse.equinox.p2.processing.Pack200Unpacker' required='true'/><br />
</processing><br />
<properties size='12'><br />
<!-- ... --><br />
<property name='download.stats' value='bundle/1.0.0.123abc'/><br />
<!-- ... --><br />
</properties><br />
</artifact><br />
</source><br />
<br />
=== Extra artifact repository properties (like p2.statsURI or p2.mirrorsURL) ===<br />
<br />
{{bug|341744}}<br />
<br />
The <tt>tycho-p2-repository-plugin:assemble-repository</tt> plugin now accepts a [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#extraArtifactRepositoryProperties extraArtifactRepositoryProperties] parameter to configure addition properties to add to the artifact repository. Typical examples of properties one would like to include that way are <tt>p2.mirrorsURL</tt> and <tt>p2.statsURI</tt><br />
<br />
<source lang="xml"><br />
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br />
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"><br />
<modelVersion>4.0.0</modelVersion><br />
<br />
<packaging>eclipse-repository</packaging><br />
<!-- .... --><br />
<build><br />
<plugins><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-p2-repository-plugin</artifactId><br />
<version>${tycho-version}</version><br />
<configuration><br />
<extraArtifactRepositoryProperties><br />
<p2.statsURI>http://some.where</p2.statsURI><br />
<p2.mirrorsURL>http://some.where.else</p2.mirrorsURL><br />
<foo>bar</foo><br />
</extraArtifactRepositoryProperties><br />
</configuration><br />
</plugin><br />
</plugins><br />
</build><br />
</project><br />
</source><br />
<br />
<br />
adds the properties to the artifact repository, that would then contain<br />
<br />
<source lang="xml"><br />
<repository name="Example Repository" type="org.eclipse.equinox.p2.artifact.repository.simpleRepository" version="1"><br />
<properties size="5"><br />
<property name="publishPackFilesAsSiblings" value="true"/><br />
<property name="p2.mirrorsURL" value="http://some.where.else"/><br />
<property name="p2.statsURI" value="http://some.where"/><br />
<property name="p2.timestamp" value="1538498332220"/><br />
<property name="foo" value="bar"/><br />
</properties><br />
<!-- .... --><br />
</source><br />
<br />
=== Configure trimStackTrace in Tycho Surefire ===<br />
<br />
{{bug|535881}}<br />
<br />
Maven Surefire aggressively trims stack traces in test case failure reports, which can lead to confusion where an error/exception actually happened. To avoid that Tycho Surefire now allows configuring the [http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace trimStackTrace property] as in Maven Surefire.<br />
<br />
[[Category:Tycho|Release Notes/1.3]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.3&diff=429626Tycho/Release Notes/1.32018-12-07T08:58:22Z<p>Michael.keppler.gmx.de: add trimStackTrace configuration</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css> <br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.2|&lt; Previous Version]] | Next Version &gt;</div> <br />
<br />
== SNAPSHOT builds ==<br />
<br />
Tycho 1.3.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.3.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://ci.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.3.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.3.0-SNAPSHOT]<br />
<br />
<br />
=== Java 11 ===<br />
<br />
* JDT was updated to 3.15.1 (we are now using ecj binaries from maven central as opposed to jdt.core and jdt.compiler.apt) {{bug|532302}}<br />
<br />
<br />
=== org.apache.felix.scr ===<br />
<br />
<br />
{{bug|538729}}<br />
<br />
Tycho 1.3.0 surefire plugin supports starting applications that use org.apache.felix.scr bundle in place of org.eclipse.equinox.ds (like Eclipse Platform 4.10 based target-platforms)<br />
<br />
=== download.stats artifact metadata property ===<br />
<br />
{{bug|539552}}<br />
<br />
Support for <tt>download.stats</tt> property on artifacts metadata. In order to (partially) enable p2 download stats as documented in [[Equinox_p2_download_stats]], you can now configure you <tt>tycho-p2-plugin:p2-metadata</tt> [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/tycho-p2/tycho-p2-plugin/p2-metadata-mojo.html#generateDownloadStatsProperty generateDownloadStats parameter] to add the necessary property on the artifacts:<br />
<br />
<source lang="xml"><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-p2-plugin</groupId><br />
<configuration><br />
<generateDownloadStatsProperty>true</generateDownloadStatsProperty><br />
</configuration><br />
</plugin><br />
</source><br />
<br />
<br />
or alternatively, you can override the <tt>tycho.generateDownloadStatsProperty</tt> property either by CLI with <tt>mvn -Dtycho.generateDownloadStatsProperty=true ...</tt> or by adding <tt><tycho.generateDownloadStatsProperty>true</tycho.generateDownloadStatsProperty></tt> in the <tt><properties></tt> element of your pom.xml.<br />
<br />
This results in this in artifacts.xml (and derived artifacts.jar and artifacts.xml.xz):<br />
<source lang="xml"><br />
<artifacts size='4'><br />
<artifact classifier='osgi.bundle' id='bundle' version='1.0.0.123abc'><br />
<properties size='9'><br />
<!-- ... --><br />
<property name='download.stats' value='bundle/1.0.0.123abc'/><br />
<!-- ... --><br />
</properties><br />
</artifact><br />
<artifact classifier='osgi.bundle' id='bundle' version='1.0.0.123abc'><br />
<processing size='1'><br />
<step id='org.eclipse.equinox.p2.processing.Pack200Unpacker' required='true'/><br />
</processing><br />
<properties size='12'><br />
<!-- ... --><br />
<property name='download.stats' value='bundle/1.0.0.123abc'/><br />
<!-- ... --><br />
</properties><br />
</artifact><br />
</source><br />
<br />
=== Extra artifact repository properties (like p2.statsURI or p2.mirrorsURL) ===<br />
<br />
{{bug|341744}}<br />
<br />
The <tt>tycho-p2-repository-plugin:assemble-repository</tt> plugin now accepts a [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#extraArtifactRepositoryProperties extraArtifactRepositoryProperties] parameter to configure addition properties to add to the artifact repository. Typical examples of properties one would like to include that way are <tt>p2.mirrorsURL</tt> and <tt>p2.statsURI</tt><br />
<br />
<source lang="xml"><br />
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br />
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"><br />
<modelVersion>4.0.0</modelVersion><br />
<br />
<packaging>eclipse-repository</packaging><br />
<!-- .... --><br />
<build><br />
<plugins><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-p2-repository-plugin</artifactId><br />
<version>${tycho-version}</version><br />
<configuration><br />
<extraArtifactRepositoryProperties><br />
<p2.statsURI>http://some.where</p2.statsURI><br />
<p2.mirrorsURL>http://some.where.else</p2.mirrorsURL><br />
<foo>bar</foo><br />
</extraArtifactRepositoryProperties><br />
</configuration><br />
</plugin><br />
</plugins><br />
</build><br />
</project><br />
</source><br />
<br />
<br />
adds the properties to the artifact repository, that would then contain<br />
<br />
<source lang="xml"><br />
<repository name="Example Repository" type="org.eclipse.equinox.p2.artifact.repository.simpleRepository" version="1"><br />
<properties size="5"><br />
<property name="publishPackFilesAsSiblings" value="true"/><br />
<property name="p2.mirrorsURL" value="http://some.where.else"/><br />
<property name="p2.statsURI" value="http://some.where"/><br />
<property name="p2.timestamp" value="1538498332220"/><br />
<property name="foo" value="bar"/><br />
</properties><br />
<!-- .... --><br />
</source><br />
<br />
=== Configure trimStackTrace in Tycho Surefire ===<br />
Maven Surefire aggressively trims stack traces in test case failure reports, which can lead to confusion where an error/exception actually happened. To avoid that Tycho Surefire now allows configuring the [http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#trimStackTrace trimStackTrace property] as in Maven Surefire.<br />
<br />
[[Category:Tycho|Release Notes/1.3]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Planet_Eclipse_Administration&diff=428887Planet Eclipse Administration2018-10-26T16:53:22Z<p>Michael.keppler.gmx.de: typo</p>
<hr />
<div>This page is for documenting changes to [[PlanetEclipse|Planet Eclipse]]. <br />
<br />
<br> <br />
<br />
== Administrators ==<br />
<br />
*Gunnar Wagenknecht <br />
*Chris Aniszczyk <br />
*Eclipse Webmaster <br />
*Ian Bull<br />
<br />
<br> <br />
<br />
== Bugzilla ==<br />
<br />
We use Bugzilla to track any feed requests. We also use tags to indicate the category of a feed request. <br />
<br />
=== Tags ===<br />
<br />
*none - [http://planet.eclipse.org/planet/ Planet Eclipse] <br />
*[universe] - [http://planet.eclipse.org/planet/universe/ Eclipse Universe]<br />
<br />
Note, tags need to be added as prefix to the bug summary.<br />
<br />
=== Shortcuts ===<br />
<br />
*[https://bugs.eclipse.org/bugs/buglist.cgi?&component=PlanetEclipse.org&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED All Open Issues]<br />
<br />
<br> <br />
<br />
== Planet Bookmarks ==<br />
<br />
*[http://planetplanet.org/] - The home page<br />
<br />
<br> <br />
<br />
== SCM Access ==<br />
git clone https://git.eclipse.org/r/planeteclipse.org/planeteclipse.org<br />
<br />
* https://git.eclipse.org/r/#/admin/projects/planeteclipse.org/planeteclipse.org<br />
* Upload your SSH public keys to Gerrit if you wish to use SSH: https://git.eclipse.org/r/#/settings/ssh-keys<br />
<br />
<br />
=== Feed Configuration Files ===<br />
<br />
*<code>planet/eclipse/feeds/community.ini</code> - [http://planet.eclipse.org/planet/ Planet Eclipse] <br />
*<code>planet/eclipse/feeds/ecosystem.ini</code> - [http://planet.eclipse.org/planet/universe/ Eclipse Universe]<br />
<br />
=== Faces ===<br />
<br />
*<code>planet/output/images/faces/</code><br />
<br />
=== Templates/UI ===<br />
<br />
*<code>planet/eclipse/index.html.tmpl</code> <br />
*<code>planet/output/css/</code><br />
<br />
== Configuration Hints ==<br />
<br />
*Use simple names for blog names, i.e. no suffixes or annotations in braces behind a name.<br />
<br />
<br> <br />
<br />
[[Category:Planet_Eclipse]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=428669EGit/Contributor Guide2018-10-15T18:02:01Z<p>Michael.keppler.gmx.de: /* Automated Developer Setup */</p>
<hr />
<div>= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[http://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Automated Developer Setup =<br />
The fastest developer setup for contributing to JGit/EGit is to use the Eclipse Installer and the<br />
EGit project setup to prepare an Eclipse IDE for JGit/EGit:<br />
* download and unpack the [https://www.eclipse.org/downloads/eclipse-packages/ Eclipse Installer]<br />
* start the Eclipse Installer<br />
* select the advanced mode<br />
[[File:Oomph-01-advanced-mode.png]]<br />
* if the right most icon in the bottom toolbar of the installer rotates, there is an update available for the installer, which should be installed before continuing<br />
* if you are behind a proxy, change the proxy settings from the toolbar at the bottom<br />
[[File:Oomph -01a-proxy-settings.png]]<br />
* on the product page select "Eclipse IDE for Eclipse Committers" and click "Next"<br />
[[File:Oomph-02-proxy-product-selection.png]]<br />
* on the project page select project "EGit" and click "Next"<br />
[[File:Oomph-03-project-egit.png]]<br />
* on Variables page accept default target platform, to fine tune variables click "Show all variables", click "Next"<br />
* on the Confirmation page click "Finish"<br />
[[File:Oomph-04-installer-progress.png]]<br />
* the installer installs the chosen IDE and starts it, as soon as the installer says "Press Finish to close the dialog" you can close the installer window<br />
* the newly installed IDE will automatically clone the JGit and EGit repositories and configure the workbench for JGit/EGit development. You can observe the setup progress in the toolbar, if necessary you can reopen the setup wizard by clicking its icon in the status bar<br />
[[File:Oomph-05-eclipse-progress.png]]<br />
* when the setup finished the IDE should looks similar to this<br />
[[File:Oomph-06-ide.png]]<br />
<br />
If you want to improve the EGit project setup, check the setup file in tools\oomph\EGit.setup (in your newly cloned egit repository). You can find more information about Oomph here<br />
* http://help.eclipse.org/<br />
* https://projects.eclipse.org/projects/tools.oomph<br />
* https://wiki.eclipse.org/Eclipse_Installer<br />
* https://wiki.eclipse.org/Eclipse_Oomph_Authoring<br />
<br />
= Manual Developer Setup =<br />
== Obtaining Sources ==<br />
EGit and JGit are self hosted in Git. You can browse the repositories on the web: <br />
[http://git.eclipse.org/c/egit/ EGit], [http://git.eclipse.org/c/jgit/ JGit]<br />
<br />
The first section below describes how to clone a repository and can be skipped if you have done this before.<br />
The next section lists the repositories and their URLs.<br />
<br />
=== Cloning ===<br />
==== On the command line ====<br />
<br />
<pre style="width: 40em;"><br />
git clone <enter URL><br />
</pre><br />
<br />
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.<br />
<br />
==== Using EGit (see [http://www.eclipse.org/egit/download/ download page]) ====<br />
<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
Then, clone the repository and import the projects:<br />
<br />
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''<br />
* Selet ''URI''<br />
* Enter the URL (see next section) <br />
* Import existing projects into the workspace from the newly created working directory<br />
<br />
=== Repositories ===<br />
<br />
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed. <br />
<br />
==== EGit ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit.git<br />
<br />
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.<br />
<br />
==== JGit ====<br />
<br />
URL: https://git.eclipse.org/r/jgit/jgit.git<br />
<br />
This is the Java implementation of Git used by EGit, for working with Git repositories.<br />
<br />
==== EGit GitHub Integration ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-github.git<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
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''.<br />
<br />
==== EGit PDE Tools ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-pde.git<br />
<br />
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. <br />
<br />
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 Git in your workspaces.<br />
<br />
== Development IDE Configuration ==<br />
<br />
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:<br />
<br />
https://www.eclipse.org/downloads/packages/<br />
<br />
=== Tools ===<br />
<br />
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:<br />
<br />
* File > Import > Install > Install Software Items from File<br />
* Browse...<br />
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''<br />
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it<br />
* All the items you don't already have should be selected automatically<br />
* Finish the wizard<br />
* Restart<br />
<br />
=== Java Requirements ===<br />
<br />
EGit and JGit have Java 8.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 4.4 (Luna)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.<br />
<br />
We are using ''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 8. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].<br />
<br />
=== Dependencies ===<br />
<br />
After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies.<br />
Set a Target Platform to fix this<br />
<br />
[[Image:EGit-Target-Platforms.png|right|EGit target platforms in org.eclipse.egit.target]]<br />
* Open the ''org.eclipse.egit.target'' project<br />
* 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)<br />
* 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)<br />
<br />
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,<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
= Running EGit from Eclipse =<br />
<br />
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:<br />
<br />
* Right click on the ''org.eclipse.egit.ui'' project<br />
* Debug As &gt; Eclipse Application<br />
<br />
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.<br />
<br />
The launch configuration can also be used in normal (non-debug) mode of course.<br />
<br />
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 />
<br/><br />
<br />
= Builds =<br />
<br />
The central EGit and JGit builds run on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson instance]<br />
<br />
Prerequisites for the Maven build are<br />
* [http://maven.apache.org/download.html at least Maven 3.5.2]<br />
* see [http://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration<br />
* if you want to learn how Maven works start reading [http://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]<br />
<br />
Hudson<br />
* [https://hudson.eclipse.org/egit/master development build jobs]<br />
* [https://hudson.eclipse.org/egit/stable maintenance and release build jobs]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven or Bazel<br />
* use Java 8 to run the JGit build<br />
* JGit packaging projects (Eclipse features and p2 repository) are built using Maven and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build ==<br />
* Due to a [http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts 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.<br />
* The local maven builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html <br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit-github<br />
<br />
[~/src/egit-github] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository<br />
<br />
in the same way you can configure a custom path for the build of egit-github to the egit p2 repository<br />
<br />
[~/src/egit-github] $ mvn clean install -Degit-site=file:/path/to/egit/org.eclipse.egit.repository/target/repository<br />
<br />
The hudson build on build.eclipse.org uses (for SNAPSHOT builds):<br />
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/<br />
org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/<br />
<br />
If you wan to build EGit for the specific Photon (4.8) platform, consider using the <code>egit-4.8</code> target platform:<br />
[~/src/egit] $ mvn -Dtarget-platform=egit-4.8 clean install<br />
<br />
For EGit version 4.10, <code>egit-4.5</code> (Mars, Eclipse 4.5), <code>egit-4.6</code> (Neon, Eclipse 4.6), <code>egit-4.7</code> (Oxygen, Eclipse 4.7), and <code>egit-4.8</code> (Photon, Eclipse 4.8) are available. In addition <code>egit-4.8-staging</code> refers to the Photon staging repository.<br />
<br />
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.7. If you skip setting the system property <code>target-platform</code> the target platform for Eclipse 4.7 will be used.<br />
<br />
==JGit Bazel Build==<br />
Since Gerrit is built using [https://www.bazel.io/ Bazel] a Bazel build was also implemented for JGit.<br />
This simplifies working on Gerrit features which also require changes in JGit.<br />
* [https://www.bazel.io/versions/master/docs/install.html Install Bazel]<br />
* To build all libraries run<br />
bazel build :all<br />
* The following test labels are supported: api, attributes, dfs, diff, http, lfs, lfs-server, nls, notes, pack, patch, pgm, reftree, revplot, revwalk, storage, submodule, symlinks, transport, treewalk, util<br />
* To run all tests execute<br />
bazel test //...<br />
* To run specific tests, using labels:<br />
bazel test --test_tag_filters=api,dfs,revplot,treewalk //...<br />
* to run build with [https://github.com/google/error-prone the errorprone static analyzer] execute<br />
bazel build --java_toolchain //tools:error_prone_warnings_toolchain :all<br />
<br />
Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://hudson.eclipse.org/egit/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Checking for JGit API Changes using API Baseline ==<br />
<br />
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:<br />
* 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.9.1</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<br />
* in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.9.1) and point it to the local copy of the corresponding EGit p2 repository.<br />
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems<br />
* see the [http://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.<br />
<br />
== Signing and Publishing ==<br />
EGit and JGit builds running on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson] are automatically signed <br />
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder<br />
<pre><br />
master branch: /home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
latest stable branch: /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly<br />
</pre><br />
<br />
* 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/<br />
* 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.<br />
<br />
== Contribution to Release Train ==<br />
<br />
The release train contribution for JGit and EGit is maintained in the git repository <br />
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre><br />
in the file<br />
<pre>egit.b3aggrcon</pre><br />
<br />
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 />
<br/><br />
<br />
= Documentation =<br />
== JGit ==<br />
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}.<br />
E.g. http://download.eclipse.org/jgit/site/4.4.1.201607150455-r/<br />
<br />
Generating the site:<br />
'''$ mvn site:site'''<br />
<br />
Staging the site locally under ./target/staging:<br />
'''$ mvn site:stage'''<br />
<br />
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:<br />
'''$ mvn site:deploy'''<br />
The site is deployed under http://download.eclipse.org/jgit/site/${project.version}<br />
<br />
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:<br />
<server><br />
<id>jgit.website</id><br />
<username>username</username><br />
<privateKey>${user.home}/.ssh/id_rsa</privateKey><br />
<password>{<encrypted passphrase>}</password><br />
<filePermissions>664</filePermission><br />
<directoryPermissions>775</directoryPermissions><br />
<configuration></configuration><br />
</server><br />
<br />
Password encryption for Maven is described in https://maven.apache.org/guides/mini/guide-encryption.html<br />
<br />
To deploy the site from JGit HIPP (Hudson) at https://hudson.eclipse.org/jgit/ enable the Maven profile '''build-server''' and add the Maven goals '''site:site site:deploy'''.<br />
<br />
If you uploaded the site for a new release update the index<br />
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html<br />
to refer to the new release's site.<br />
<br />
== EGit ==<br />
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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.<br />
<br />
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].<br />
<br />
Alternatively, install "Jetty 9.2.10.v20150310" from http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.10.v20150310/<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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''.<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":<br />
* http://download.eclipse.org/technology/swtbot/snapshots/<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== During Maven Build ===<br />
<br />
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].<br />
<br />
If you want to skip execution of UI tests (only execute core tests):<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
If you want to skip all tests:<br />
<br />
mvn clean install -Dmaven.test.skip=true<br />
<br />
== Auxilary testing tools ==<br />
<br />
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.<br />
<br />
= Bugs =<br />
<br />
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":<br />
<br />
[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]<br />
<br />
[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]<br />
<br />
== Links ==<br />
=== Filing Bugs ===<br />
==== How to file bugs ==== <br />
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]] <br />
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]<br />
*[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham<br />
<br />
==== File a bug ====<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
==== File a bug for a vulnerability ====<br />
If you discovered a vulnerability you want to report <br />
* create a bug in Bugzilla here https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit<br />
* click "Show Advanced Fields" <br />
* and check the option "Committer-only group for handling security advisories in a closed fashion."<br />
* describe the vulnerability<br />
this will ensure that the discussion on the vulnerability is kept private between the reporter and the committer group<br />
until the project prepared a release fixing the vulnerability<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends (bugs and enhancements)<br />
!EGit <br />
!JGit<br />
|-<br />
|Open by component (date range editable)<br />
|[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] <br />
|[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]<br />
|-<br />
|Open by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|-<br />
|Assigned <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned] <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|Open and closed by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed target milestones</span> <br />
| [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]<br />
| [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]<br />
|-<br />
| Open bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open enhancements<br />
| [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]<br />
| [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]<br />
|-<br />
| Bugs with votes<br />
| [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]<br />
| [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]<br />
|-<br />
|Assigned bugs and enhancements <br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit bugs<br />
| 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]<br />
|-<br />
| New bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><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''.<br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
== Spam Bugs ==<br />
If you come across spam bugs you can request webmaster to delete them by marking them as duplicate of bug 442999.<br />
<br />
Also see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=502814 bug 502814]<br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.<br />
<br />
'''egit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''<br />
* 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 />
'''jgit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''<br />
* 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 />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
== Using Gerrit at Eclipse ==<br />
<br />
EGit and JGit projects are using [https://www.gerritcodereview.com/ Gerrit Code Review] for Git based patch submission and review. <br />
<br />
Parts of this chapter are also available in the [http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].<br />
<br />
=== User Account ===<br />
*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.<br />
<br />
=== Legal Paperwork ===<br />
<br />
Before your first contribution can be accepted, you need to electronically sign the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement] (ECA). The ECA is good for three years. Find more information in the [https://www.eclipse.org/legal/ecafaq.php ECA FAQ].<br />
<br />
Minimally, all Git commits you contribute must have the following:<br />
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;<br />
* Your credentials (email address) captured in the "Author" field; and<br />
* A "Signed-off-by" entry with matching credentials in the comment.<br />
* The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the [https://www.eclipse.org/legal/DCO.php Developer Certificate of Origin].<br />
<br />
In addition ensure<br />
* that the contributed code is licensed under the project license (EPL 2.0 for EGit and EDL 1.0 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.<br />
<br />
With a valid ECA 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.<br />
<br />
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:<br />
* If it's committed: git log --shortstat<br />
* If not committed: git diff --stat<br />
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.<br />
<br />
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)].<br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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.]<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[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].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** 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.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** 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.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
== Granularity of Changes ==<br />
<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
<br />
=== Branches ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedence.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
=== Braces for one-line statements ===<br />
<br />
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.:<br />
<br />
if (condition)<br />
doSomething();<br />
<br />
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:<br />
<br />
if (condition) {<br />
doSomething();<br />
}<br />
<br />
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}}.<br />
<br />
=== Removing trailing whitespace ===<br />
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}}.<br />
<br />
As a workaround, use the following sequence of commands in the Java editor to trick the save action:<br />
* remove the offending trailing whitespace<br />
* the save action re-adds the trailing whitespace<br />
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again<br />
<br />
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.<br />
<br />
=== Use of the "final" modifier ===<br />
<br />
New code uses the "final" modifier in the following circumstances[https://gerrit-review.googlesource.com/c/gerrit/+/61701/].<br />
<br />
Always:<br />
* final fields: marking fields as final forces them to be initialized in the constructor or at declaration<br />
* final static fields: clearly communicates the intent<br />
* where necessary to use final variables in inner anonymous classes<br />
<br />
Optional:<br />
* final classes: use when appropriate, e.g. API restriction<br />
* final methods: similar to final classes<br />
<br />
Never:<br />
* local variables: it clutters the code, and makes the code less readable. When copying old code to new location, finals should be removed<br />
* method parameters: similar to local variables<br />
<br />
== Commit message guidelines ==<br />
<br />
*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.<br />
*The first line should be a clear and concise description about the change and should not end with a dot.<br />
*In case of release engineering tasks without bugzilla entries the commit message header may look like "[findbugs] Fix warning XYZ for String constructor". The prefix in brackets is an indication why this comes without a corresponding bug. <br />
*Enter a newline before providing a more detailed description about the change.<br />
*Format the commit message to have newline characters after every 60-70 characters. <br />
*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"]<br />
*''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.<br />
**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. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.<br />
**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<br />
**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''.<br />
**A "Signed-off-by" can be added at the end of the commit message (see example below). Note: At the moment this footer is not required for committers, but for non-committer contributors. It may be used to list all who modified (amended, rebased, cherry-picked) this change.<br />
<br />
<pre>Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
CQ: 6031<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
If you use Mylyn to fetch a bug from bugzilla, and then activate the task, the commit message will automatically be formatted exactly like requested above.<br />
<br />
== Copyright ==<br />
<br />
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.<br />
<br />
When there is only one copyright present (from a person or a company), like this:<br />
<br />
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org><br />
</pre><br />
<br />
Change it like this (notice the updated year):<br />
<br />
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.<br />
</pre><br />
<br />
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.<br />
<br />
When there are multiple copyright entries there, add yours as a separate line. So, given this:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
</pre><br />
<br />
Add another line:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
Copyright (C) YEAR Your Name <you@example.org><br />
</pre><br />
<br />
For new files, copy one of the existing headers and start the copyright section with your name.<br />
<br />
Also see http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.<br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
* Add automated tests for enhancements and bug fixes to ensure functional correctness and avoid regressions<br />
* Run all existing tests. It does not take very long.<br />
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 8 and Eclipse 4.4. You cannot use API's that are newer.<br />
<br />
== Sending patches by mail ==<br />
<br />
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 [http://www.kernel.org/pub//software/scm/git/docs/git-send-email.html git send-email]. Instead, please use [http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html git format-patch] to generate the <code>mbox</code>, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides. <br />
<br />
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. <br />
<br />
'''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 />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
We have build jobs '''jgit.gerrit''' on https://hudson.eclipse.org/jgit/, and '''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.<br />
<br />
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.<br />
Committers can manually trigger these jobs in the following way:<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
If you are not a committer and need to retrigger a build ask for that on the mailing list.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=428571EGit/Contributor Guide2018-10-09T12:24:17Z<p>Michael.keppler.gmx.de: /* Commit message guidelines */</p>
<hr />
<div>= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[http://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Automated Developer Setup =<br />
The fastest developer setup for contributing to JGit/EGit is to use the Eclipse Installer and the<br />
EGit project setup to prepare an Eclipse IDE for JGit/EGit:<br />
* download and unpack the [https://www.eclipse.org/downloads/eclipse-packages/ Eclipse Installer]<br />
* start the Eclipse Installer<br />
* select the advanced mode<br />
[[File:Oomph-01-advanced-mode.png]]<br />
* on the product page<br />
** if you are behind a proxy open the proxy settings from the toolbar at the bottom<br />
[[File:Oomph -01a-proxy-settings.png]]<br />
** select "Eclipse IDE for Eclipse Committers" and click "Next"<br />
[[File:Oomph-02-proxy-product-selection.png]]<br />
* on the project page select project "EGit" and click "Next"<br />
[[File:Oomph-03-project-egit.png]]<br />
* on Variables page accept default target platform, to fine tune variables click "Show all variables", click "Next"<br />
* on the Confirmation page click "Finish"<br />
[[File:Oomph-04-installer-progress.png]]<br />
* the installer installs the chosen IDE and starts it, as soon as the installer says "Press Finish to close the dialog" you can close the installer window<br />
* the newly installed IDE will automatically clone the JGit and EGit repositories and configure the workbench for JGit/EGit development. You can observe the setup progress in the toolbar, if necessary you can reopen the setup wizard by clicking its icon in the status bar<br />
[[File:Oomph-05-eclipse-progress.png]]<br />
* when the setup finished the IDE should looks similar to this<br />
[[File:Oomph-06-ide.png]]<br />
<br />
If you want to improve the EGit project setup you find more information about Oomph here<br />
* http://help.eclipse.org/<br />
* https://projects.eclipse.org/projects/tools.oomph<br />
* https://wiki.eclipse.org/Eclipse_Installer<br />
* https://wiki.eclipse.org/Eclipse_Oomph_Authoring<br />
<br />
= Manual Developer Setup =<br />
== Obtaining Sources ==<br />
EGit and JGit are self hosted in Git. You can browse the repositories on the web: <br />
[http://git.eclipse.org/c/egit/ EGit], [http://git.eclipse.org/c/jgit/ JGit]<br />
<br />
The first section below describes how to clone a repository and can be skipped if you have done this before.<br />
The next section lists the repositories and their URLs.<br />
<br />
=== Cloning ===<br />
==== On the command line ====<br />
<br />
<pre style="width: 40em;"><br />
git clone <enter URL><br />
</pre><br />
<br />
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.<br />
<br />
==== Using EGit (see [http://www.eclipse.org/egit/download/ download page]) ====<br />
<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
Then, clone the repository and import the projects:<br />
<br />
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''<br />
* Selet ''URI''<br />
* Enter the URL (see next section) <br />
* Import existing projects into the workspace from the newly created working directory<br />
<br />
=== Repositories ===<br />
<br />
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed. <br />
<br />
==== EGit ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit.git<br />
<br />
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.<br />
<br />
==== JGit ====<br />
<br />
URL: https://git.eclipse.org/r/jgit/jgit.git<br />
<br />
This is the Java implementation of Git used by EGit, for working with Git repositories.<br />
<br />
==== EGit GitHub Integration ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-github.git<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
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''.<br />
<br />
==== EGit PDE Tools ====<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-pde.git<br />
<br />
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. <br />
<br />
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 Git in your workspaces.<br />
<br />
== Development IDE Configuration ==<br />
<br />
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:<br />
<br />
https://www.eclipse.org/downloads/packages/<br />
<br />
=== Tools ===<br />
<br />
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:<br />
<br />
* File > Import > Install > Install Software Items from File<br />
* Browse...<br />
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''<br />
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it<br />
* All the items you don't already have should be selected automatically<br />
* Finish the wizard<br />
* Restart<br />
<br />
=== Java Requirements ===<br />
<br />
EGit and JGit have Java 8.0 and [https://wiki.eclipse.org/EGit/FAQ#What_versions_of_Eclipse_does_EGit_target.3F Eclipse Platform 4.4 (Luna)] as minimum requirements, so dependencies to newer Java and platform versions must be avoided.<br />
<br />
We are using ''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 8. If you followed the instructions in the ''Tools'' section above, the necessary descriptions should already be installed. Otherwise install ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].<br />
<br />
=== Dependencies ===<br />
<br />
After importing the EGit and JGit projects in Eclipse, they will not compile due to missing dependencies.<br />
Set a Target Platform to fix this<br />
<br />
[[Image:EGit-Target-Platforms.png|right|EGit target platforms in org.eclipse.egit.target]]<br />
* Open the ''org.eclipse.egit.target'' project<br />
* 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)<br />
* 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)<br />
<br />
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,<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
= Running EGit from Eclipse =<br />
<br />
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:<br />
<br />
* Right click on the ''org.eclipse.egit.ui'' project<br />
* Debug As &gt; Eclipse Application<br />
<br />
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.<br />
<br />
The launch configuration can also be used in normal (non-debug) mode of course.<br />
<br />
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 />
<br/><br />
<br />
= Builds =<br />
<br />
The central EGit and JGit builds run on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson instance]<br />
<br />
Prerequisites for the Maven build are<br />
* [http://maven.apache.org/download.html at least Maven 3.5.2]<br />
* see [http://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration<br />
* if you want to learn how Maven works start reading [http://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]<br />
<br />
Hudson<br />
* [https://hudson.eclipse.org/egit/master development build jobs]<br />
* [https://hudson.eclipse.org/egit/stable maintenance and release build jobs]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven or Bazel<br />
* use Java 8 to run the JGit build<br />
* JGit packaging projects (Eclipse features and p2 repository) are built using Maven and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build ==<br />
* Due to a [http://wiki.eclipse.org/Tycho/How_Tos/Dependency_on_pom-first_artifacts 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.<br />
* The local maven builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html <br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit-github<br />
<br />
[~/src/egit-github] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/jgit/org.eclipse.jgit.packaging/org.eclipse.jgit.repository/target/repository<br />
<br />
in the same way you can configure a custom path for the build of egit-github to the egit p2 repository<br />
<br />
[~/src/egit-github] $ mvn clean install -Degit-site=file:/path/to/egit/org.eclipse.egit.repository/target/repository<br />
<br />
The hudson build on build.eclipse.org uses (for SNAPSHOT builds):<br />
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/<br />
org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/<br />
<br />
If you wan to build EGit for the specific Photon (4.8) platform, consider using the <code>egit-4.8</code> target platform:<br />
[~/src/egit] $ mvn -Dtarget-platform=egit-4.8 clean install<br />
<br />
For EGit version 4.10, <code>egit-4.5</code> (Mars, Eclipse 4.5), <code>egit-4.6</code> (Neon, Eclipse 4.6), <code>egit-4.7</code> (Oxygen, Eclipse 4.7), and <code>egit-4.8</code> (Photon, Eclipse 4.8) are available. In addition <code>egit-4.8-staging</code> refers to the Photon staging repository.<br />
<br />
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.7. If you skip setting the system property <code>target-platform</code> the target platform for Eclipse 4.7 will be used.<br />
<br />
==JGit Bazel Build==<br />
Since Gerrit is built using [https://www.bazel.io/ Bazel] a Bazel build was also implemented for JGit.<br />
This simplifies working on Gerrit features which also require changes in JGit.<br />
* [https://www.bazel.io/versions/master/docs/install.html Install Bazel]<br />
* To build all libraries run<br />
bazel build :all<br />
* The following test labels are supported: api, attributes, dfs, diff, http, lfs, lfs-server, nls, notes, pack, patch, pgm, reftree, revplot, revwalk, storage, submodule, symlinks, transport, treewalk, util<br />
* To run all tests execute<br />
bazel test //...<br />
* To run specific tests, using labels:<br />
bazel test --test_tag_filters=api,dfs,revplot,treewalk //...<br />
<br />
Note that the Bazel build does not yet support building JGit OSGi bundles, Eclipse features and the p2 repository which are required to install JGit in Eclipse.<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://hudson.eclipse.org/egit/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Checking for JGit API Changes using API Baseline ==<br />
<br />
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:<br />
* 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.9.1</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<br />
* in Eclipse click "Preferences > Plug-In Development > API Baselines", click "Add Baseline..." and define a new baseline (e.g. egit-4.9.1) and point it to the local copy of the corresponding EGit p2 repository.<br />
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems<br />
* see the [http://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.<br />
<br />
== Signing and Publishing ==<br />
EGit and JGit builds running on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson] are automatically signed <br />
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder<br />
<pre><br />
master branch: /home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
latest stable branch: /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly<br />
</pre><br />
<br />
* 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/<br />
* 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.<br />
<br />
== Contribution to Release Train ==<br />
<br />
The release train contribution for JGit and EGit is maintained in the git repository <br />
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre><br />
in the file<br />
<pre>egit.b3aggrcon</pre><br />
<br />
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 />
<br/><br />
<br />
= Documentation =<br />
== JGit ==<br />
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}.<br />
E.g. http://download.eclipse.org/jgit/site/4.4.1.201607150455-r/<br />
<br />
Generating the site:<br />
'''$ mvn site:site'''<br />
<br />
Staging the site locally under ./target/staging:<br />
'''$ mvn site:stage'''<br />
<br />
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:<br />
'''$ mvn site:deploy'''<br />
The site is deployed under http://download.eclipse.org/jgit/site/${project.version}<br />
<br />
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:<br />
<server><br />
<id>jgit.website</id><br />
<username>username</username><br />
<privateKey>${user.home}/.ssh/id_rsa</privateKey><br />
<password>{<encrypted passphrase>}</password><br />
<filePermissions>664</filePermission><br />
<directoryPermissions>775</directoryPermissions><br />
<configuration></configuration><br />
</server><br />
<br />
Password encryption for Maven is described in https://maven.apache.org/guides/mini/guide-encryption.html<br />
<br />
To deploy the site from JGit HIPP (Hudson) at https://hudson.eclipse.org/jgit/ enable the Maven profile '''build-server''' and add the Maven goals '''site:site site:deploy'''.<br />
<br />
If you uploaded the site for a new release update the index<br />
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html<br />
to refer to the new release's site.<br />
<br />
== EGit ==<br />
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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.<br />
<br />
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].<br />
<br />
Alternatively, install "Jetty 9.2.10.v20150310" from http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.10.v20150310/<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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''.<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":<br />
* http://download.eclipse.org/technology/swtbot/snapshots/<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== During Maven Build ===<br />
<br />
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].<br />
<br />
If you want to skip execution of UI tests (only execute core tests):<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
If you want to skip all tests:<br />
<br />
mvn clean install -Dmaven.test.skip=true<br />
<br />
== Auxilary testing tools ==<br />
<br />
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.<br />
<br />
= Bugs =<br />
<br />
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":<br />
<br />
[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]<br />
<br />
[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]<br />
<br />
== Links ==<br />
=== Filing Bugs ===<br />
==== How to file bugs ==== <br />
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]] <br />
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]<br />
*[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham<br />
<br />
==== File a bug ====<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
==== File a bug for a vulnerability ====<br />
If you discovered a vulnerability you want to report <br />
* create a bug in Bugzilla here https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit<br />
* click "Show Advanced Fields" <br />
* and check the option "Committer-only group for handling security advisories in a closed fashion."<br />
* describe the vulnerability<br />
this will ensure that the discussion on the vulnerability is kept private between the reporter and the committer group<br />
until the project prepared a release fixing the vulnerability<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends (bugs and enhancements)<br />
!EGit <br />
!JGit<br />
|-<br />
|Open by component (date range editable)<br />
|[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] <br />
|[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]<br />
|-<br />
|Open by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|-<br />
|Assigned <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned] <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|Open and closed by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed target milestones</span> <br />
| [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]<br />
| [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]<br />
|-<br />
| Open bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open enhancements<br />
| [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]<br />
| [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]<br />
|-<br />
| Bugs with votes<br />
| [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]<br />
| [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]<br />
|-<br />
|Assigned bugs and enhancements <br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit bugs<br />
| 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]<br />
|-<br />
| New bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><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''.<br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
== Spam Bugs ==<br />
If you come across spam bugs you can request webmaster to delete them by marking them as duplicate of bug 442999.<br />
<br />
Also see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=502814 bug 502814]<br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.<br />
<br />
'''egit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''<br />
* 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 />
'''jgit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''<br />
* 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 />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
== Using Gerrit at Eclipse ==<br />
<br />
EGit and JGit projects are using [https://www.gerritcodereview.com/ Gerrit Code Review] for Git based patch submission and review. <br />
<br />
Parts of this chapter are also available in the [http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].<br />
<br />
=== User Account ===<br />
*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.<br />
<br />
=== Legal Paperwork ===<br />
<br />
Before your first contribution can be accepted, you need to electronically sign the [https://www.eclipse.org/legal/ECA.php Eclipse Contributor Agreement] (ECA). The ECA is good for three years. Find more information in the [https://www.eclipse.org/legal/ecafaq.php ECA FAQ].<br />
<br />
Minimally, all Git commits you contribute must have the following:<br />
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;<br />
* Your credentials (email address) captured in the "Author" field; and<br />
* A "Signed-off-by" entry with matching credentials in the comment.<br />
* The "Signed-off-by" entry is required. By including this, you confirm that you are in compliance with the [https://www.eclipse.org/legal/DCO.php Developer Certificate of Origin].<br />
<br />
In addition ensure<br />
* that the contributed code is licensed under the project license (EPL 2.0 for EGit and EDL 1.0 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.<br />
<br />
With a valid ECA 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.<br />
<br />
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:<br />
* If it's committed: git log --shortstat<br />
* If not committed: git diff --stat<br />
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.<br />
<br />
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)].<br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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.]<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[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].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** 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.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** 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.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
== Granularity of Changes ==<br />
<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
<br />
=== Branches ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedence.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
=== Braces for one-line statements ===<br />
<br />
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.:<br />
<br />
if (condition)<br />
doSomething();<br />
<br />
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:<br />
<br />
if (condition) {<br />
doSomething();<br />
}<br />
<br />
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}}.<br />
<br />
=== Removing trailing whitespace ===<br />
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}}.<br />
<br />
As a workaround, use the following sequence of commands in the Java editor to trick the save action:<br />
* remove the offending trailing whitespace<br />
* the save action re-adds the trailing whitespace<br />
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again<br />
<br />
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.<br />
<br />
=== Use of the "final" modifier ===<br />
<br />
New code uses the "final" modifier in the following circumstances[https://gerrit-review.googlesource.com/c/gerrit/+/61701/].<br />
<br />
Always:<br />
* final fields: marking fields as final forces them to be initialized in the constructor or at declaration<br />
* final static fields: clearly communicates the intent<br />
* where necessary to use final variables in inner anonymous classes<br />
<br />
Optional:<br />
* final classes: use when appropriate, e.g. API restriction<br />
* final methods: similar to final classes<br />
<br />
Never:<br />
* local variables: it clutters the code, and makes the code less readable. When copying old code to new location, finals should be removed<br />
* method parameters: similar to local variables<br />
<br />
== Commit message guidelines ==<br />
<br />
*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.<br />
*The first line should be a clear and concise description about the change and should not end with a dot.<br />
*In case of release engineering tasks without bugzilla entries the commit message header may look like "[findbugs] Fix warning XYZ for String constructor". The prefix in brackets is an indication why this comes without a corresponding bug. <br />
*Enter a newline before providing a more detailed description about the change.<br />
*Format the commit message to have newline characters after every 60-70 characters. <br />
*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"]<br />
*''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.<br />
**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. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.<br />
**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<br />
**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''.<br />
**A "Signed-off-by" can be added at the end of the commit message (see example below). Note: At the moment this footer is not required for committers, but for non-committer contributors. It may be used to list all who modified (amended, rebased, cherry-picked) this change.<br />
<br />
<pre>Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
CQ: 6031<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
If you use Mylyn to fetch a bug from bugzilla, and then activate the task, the commit message will automatically be formatted exactly like requested above.<br />
<br />
== Copyright ==<br />
<br />
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.<br />
<br />
When there is only one copyright present (from a person or a company), like this:<br />
<br />
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org><br />
</pre><br />
<br />
Change it like this (notice the updated year):<br />
<br />
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.<br />
</pre><br />
<br />
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.<br />
<br />
When there are multiple copyright entries there, add yours as a separate line. So, given this:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
</pre><br />
<br />
Add another line:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
Copyright (C) YEAR Your Name <you@example.org><br />
</pre><br />
<br />
For new files, copy one of the existing headers and start the copyright section with your name.<br />
<br />
Also see http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.<br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
* Add automated tests for enhancements and bug fixes to ensure functional correctness and avoid regressions<br />
* Run all existing tests. It does not take very long.<br />
* Pay attention to the Java and Eclipse SDK baselines. EGit requires only Java 8 and Eclipse 4.4. You cannot use API's that are newer.<br />
<br />
== Sending patches by mail ==<br />
<br />
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 [http://www.kernel.org/pub//software/scm/git/docs/git-send-email.html git send-email]. Instead, please use [http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html git format-patch] to generate the <code>mbox</code>, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides. <br />
<br />
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. <br />
<br />
'''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 />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
We have build jobs '''jgit.gerrit''' on https://hudson.eclipse.org/jgit/, and '''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.<br />
<br />
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.<br />
Committers can manually trigger these jobs in the following way:<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
If you are not a committer and need to retrigger a build ask for that on the mailing list.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/4.11&diff=425022EGit/New and Noteworthy/4.112018-05-02T16:14:16Z<p>Michael.keppler.gmx.de: fix hyperlink</p>
<hr />
<div>= EGit =<br />
==Usability==<br />
* {{bug|531328}}: Delete Repository dialog: use "Delete" instead of "OK" for button<br />
* {{bug|531431}}: Use "Close" instead of "Ok" on the confirmation button of FetchResultDialog<br />
* {{bug|531264}}: Discard Local Changes should use verbs if triggered from Staging View<br />
* {{bug|530685}}: Include local branch name in branch proposals of push branch wizard <br />
* {{bug|530685}}: Asynchronous content proposals for upstream refs in PushBranchPage<br />
* Make the PushWizardDialog a NonBlockingWizardDialog<br />
* {{bug|530757}}: Remove extra progress popup in PushBranchWizard<br />
* {{bug|510945}}: Provide option to copy file names in staging view to clipboard<br />
* {{bug|530625}}: Select "ssh" protocol also for git-style URLs without scheme<br />
* Avoid internal job being displayed in progress view<br />
<br />
==Performance Improvements==<br />
* {{bug|531948}}: Speed up getting the last commit that changed a file <br />
<br />
==Bug Fixes==<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?resolution=FIXED&resolution=DUPLICATE&classification=Technology&list_id=10006180&order=Importance&product=EGit&query_format=advanced&target_milestone=4.11 15 Bugs and 2 enhancement requests] were closed<br />
<br />
* {{bug|531527}}: Fix CSS for dark theme<br />
* {{bug|530704}}: Prevent NPE in RefContentProposal.appendObjectSummary <br />
* Prevent MissingObjectException being logged in ref content proposal<br />
* {{bug|503198}}: Fix focus handling in GitHistoryPage <br />
* {{bug|530412}}: Fix wrongly used IExtension.getNamespaceIdentifier <br />
* {{bug|521176}}: Fix non-modal PushResultDialog <br />
* {{bug|529950}}: More appealing layout on git project property page <br />
<br />
== Build and Release Engineering==<br />
* Update orbit to S20180302171354 (photon) and R20180206163158 (oxygen)<br />
* Update tycho to 1.1.0<br />
* Upgrade gson to version 2.8.2 (used by JGit)<br />
* Upgrade commons-compress to 1.15 (used by JGit)<br />
* Add com.jcraft.jzlib 1.1.1 (CQ 15293, bug 529129)<br />
* Update API baselines in Oomph setup<br />
<br />
= Contributors =<br />
The following 7 developers worked on this release:<br />
<br />
Andrey Loskutov,<br />
Fabian Pfaff,<br />
Jonas Hungershausen,<br />
Lars Vogel,<br />
Matthias Sohn,<br />
Michael Keppler,<br />
Thomas Wolf</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=IRC&diff=418829IRC2017-07-30T15:38:27Z<p>Michael.keppler.gmx.de: removed long time not existing main channels. they are gone for years and will not come back</p>
<hr />
<div>'''IRC''' is an excellent public forum -- both for helping users and for getting to know other committers. We have official group status on [http://freenode.net Freenode]. You can connect to Freenode by pointing your [[#How Do I Choose An IRC Client? | IRC client]] at irc.freenode.net. <br />
<br />
== Main Channels ==<br />
<br />
These are the main channels we maintain:<br />
* [irc://irc.freenode.net/#eclipse #eclipse] - questions from plug-in developers and users, general catch-all when specific channels do not exist. You can read [http://echelog.com/logs/browse/eclipse previous discussions].<br />
* [irc://irc.freenode.net/#eclipse-dev #eclipse-dev] - Eclipse contributors discussion and socializing - a good rule of thumb is this channel is for the development of org.eclipse.* plug-ins<br />
* [irc://irc.freenode.net/#eclipse-soc #eclipse-soc] - official channel for [[Google_Summer_of_Code|Eclipse Summer of Code]]<br />
<br />
=== Project Channels ===<br />
<br />
There are also more project specific channels:<br />
* [irc://irc.freenode.net/#eclipse-andmore #eclipse-andmore] - the official channel for Andmore and general android development with eclipse.<br />
* [irc://irc.freenode.net/#eclipse.b3 #eclipse-b3] - the build channel, buckminster, b3 project, etc (still registered but empty as of 18:06, 16 April 2013 (UTC))<br />
* [irc://irc.freenode.net/#eclipse.de #eclipse-de] - German localized version of #eclipse<br />
* [irc://irc.freenode.net/#eclipse-e4 #eclipse-e4] - official channel for E4 discussions [http://echelog.com/logs/browse/eclipse-e4 log]<br />
* [irc://irc.freenode.net/#eclipse-ecf #eclipse-ecf] - the discussion channel for the [[Eclipse Communication Framework Project|Eclipse Communication Framework]]<br />
* [irc://irc.freenode.net/#eclipse-hudson #eclipse-hudson] - the discussion channel for the [http://eclipse.org/hudson Hudson CI] project<br />
* [irc://irc.freenode.net/#eclipse-linux #eclipse-linux] - the discussion channel for the [http://www.eclipse.org/linuxtools/ Linux Tools Project]<br />
* [irc://irc.freenode.net/#eclipse-modeling #eclipse-modeling] - the discussion channel for the [http://www.eclipse.org/modeling/ Eclipse Modeling Project]<br />
* [irc://irc.freenode.net/#eclipse-orion #eclipse-orion] - official channel for the [[Orion]] project<br />
* [irc://irc.freenode.net/#eclipse-scout #eclipse-scout] - official channel for the [http://wiki.eclipse.org/Scout Eclipse Scout] project (channel '''inactive''' as of 18:06, 16 April 2013 (UTC))<br />
<br />
* [irc://irc.freenode.net/#eclipselink #eclipselink] - official channel for the [[EclipseLink]] project<br />
* [irc://irc.freenode.net/#equinox-dev #equinox-dev] - the committer/contributor discussion channel for the [http://eclipse.org/equinox Equinox Project] and p2<br />
* [irc://irc.freenode.net/#higgins #higgins] - the discussion channel for the [http://eclipse.org/higgins Higgins] project (registered but empty as of 18:06, 16 April 2013 (UTC))<br />
* [irc://irc.freenode.net/#pdt #pdt] - official channel for the [http://eclipse.org/pdt PDT] project (reclaimed by freenode-staff due to inactivity, topic updated and locked to PDT home page)<br />
<br />
=== Related Channels ===<br />
* [irc://irc.freenode.net/#osgi #osgi] - OSGi related channel<br />
<br />
== More Info ==<br />
<br />
A [http://echelog.com/logs/browse/eclipse log] of the the traffic on #eclipse is available on the web. There is also an actively maintained [[IRC FAQ]] in which most questions eventually appear -- feel free to contribute! ''Much of the content was born [http://eclipsewiki.editme.com/IrcFaq here].''<br />
<br />
If you are a committer on an eclipse project, then you can get yourself a developer cloak. A developer cloak identifies you as a committer on the Eclipse project, gives you some privileges on the channel and masks your hostname. If you would like a developer cloak, please contact '''paulweb515''' or '''nitind''' on IRC.<br />
<br />
=== How Do I Start Using IRC? ===<br />
<br />
* First, choose an IRC client (see [[#How Do I Choose An IRC Client? | below]]). <br />
* Then, read the [http://freenode.net/faq.shtml#nicksetup Freenode Setup FAQ].<br />
<br />
=== How Do I Choose An IRC Client? ===<br />
<br />
* If you are having trouble choosing an IRC client, try [http://chatzilla.hacksrus.com/ ChatZilla] which runs inside Firefox. [https://support.mozilla.org/en-US/kb/instant-messaging-and-chat Thunderbird] Konversation and xchat are also widely used options.<br />
* For GNOME you can try [http://www.smuxi.org/ Smuxi].<br />
* Or, if you're familiar with the IM client Gaim (now called [http://pidgin.im/pidgin/home/ Pidgin]), it also works great with IRC on both Windows and Linux. <br />
* Mac users, try [http://www.google.ca/search?q=mac+irc+client one of these].<br />
* Another choice is [http://www.eclipse.org/ecf ECF's IRC client], which runs as a view inside of Eclipse.<br />
* If you cannot connect due to firewall issues or prefer to not install anything, try http://webchat.freenode.net/ to connect via HTTP.<br />
<br />
=== OK, I'm Set Up, Now What? ===<br />
<br />
* Read the [[IRC_FAQ | FAQ]]. <br />
* Join a [[#Main Channels | channel]].<br />
* Post a question, or answer one.<br />
<br />
== Other Notes ==<br />
<nowiki><br />
Welcome! If you have a question, just ask, or take a look at our FAQ - http://wiki.eclipse.org/IRC_FAQ <br />
Try typing ~faq to see more FAQs! If you have errors or logs to show, see ~pastebin. <br />
If you have screenshots to share, see ~image. If you need to describe your problem, please <br />
provide some ~info about your setup. Don't ask to ask, just ask, and please be patient when <br />
waiting for a response. Lurk. Thank you and enjoy your stay.<br />
</nowiki></div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=IRC&diff=418597IRC2017-07-25T06:40:59Z<p>Michael.keppler.gmx.de: fixed channel log link</p>
<hr />
<div>'''IRC''' is an excellent public forum -- both for helping users and for getting to know other committers. We have official group status on [http://freenode.net Freenode]. You can connect to Freenode by pointing your [[#How Do I Choose An IRC Client? | IRC client]] at irc.freenode.net. <br />
<br />
== Main Channels ==<br />
<br />
These are the main channels we maintain:<br />
* [irc://irc.freenode.net/#eclipse #eclipse] - questions from plug-in developers and users [http://echelog.com/logs/browse/eclipse log], general catch-all when specific channels do not exist<br />
* [irc://irc.freenode.net/#eclipse-bugs #eclipse-bugs] - official channel for [[BugDay|Eclipse Bug Day]]s (which haven't happened since 2009)<br />
* [irc://irc.freenode.net/#eclipse-commits #eclipse-commits] - lists all commits as they come in (See [http://cia.navi.cx CIA]) ('''down''' and empty as of 18:06, 16 April 2013 (UTC))<br />
* [irc://irc.freenode.net/#eclipse-dev #eclipse-dev] - Eclipse contributors discussion and socializing - a good rule of thumb is this channel is for the development of org.eclipse.* plug-ins<br />
* [irc://irc.freenode.net/#eclipse-soc #eclipse-soc] - official channel for [[Google_Summer_of_Code|Eclipse Summer of Code]]<br />
<br />
=== Project Channels ===<br />
<br />
There are also more project specific channels:<br />
* [irc://irc.freenode.net/#eclipse-andmore #eclipse-andmore] - the official channel for Andmore and general android development with eclipse.<br />
* [irc://irc.freenode.net/#eclipse.b3 #eclipse-b3] - the build channel, buckminster, b3 project, etc (still registered but empty as of 18:06, 16 April 2013 (UTC))<br />
* [irc://irc.freenode.net/#eclipse.de #eclipse-de] - German localized version of #eclipse<br />
* [irc://irc.freenode.net/#eclipse-e4 #eclipse-e4] - official channel for E4 discussions [http://echelog.com/logs/browse/eclipse-e4 log]<br />
* [irc://irc.freenode.net/#eclipse-ecf #eclipse-ecf] - the discussion channel for the [[Eclipse Communication Framework Project|Eclipse Communication Framework]]<br />
* [irc://irc.freenode.net/#eclipse-hudson #eclipse-hudson] - the discussion channel for the [http://eclipse.org/hudson Hudson CI] project<br />
* [irc://irc.freenode.net/#eclipse-linux #eclipse-linux] - the discussion channel for the [http://www.eclipse.org/linuxtools/ Linux Tools Project]<br />
* [irc://irc.freenode.net/#eclipse-modeling #eclipse-modeling] - the discussion channel for the [http://www.eclipse.org/modeling/ Eclipse Modeling Project]<br />
* [irc://irc.freenode.net/#eclipse-orion #eclipse-orion] - official channel for the [[Orion]] project<br />
* [irc://irc.freenode.net/#eclipse-scout #eclipse-scout] - official channel for the [http://wiki.eclipse.org/Scout Eclipse Scout] project (channel '''inactive''' as of 18:06, 16 April 2013 (UTC))<br />
<br />
* [irc://irc.freenode.net/#eclipselink #eclipselink] - official channel for the [[EclipseLink]] project<br />
* [irc://irc.freenode.net/#equinox-dev #equinox-dev] - the committer/contributor discussion channel for the [http://eclipse.org/equinox Equinox Project] and p2<br />
* [irc://irc.freenode.net/#higgins #higgins] - the discussion channel for the [http://eclipse.org/higgins Higgins] project (registered but empty as of 18:06, 16 April 2013 (UTC))<br />
* [irc://irc.freenode.net/#pdt #pdt] - official channel for the [http://eclipse.org/pdt PDT] project (reclaimed by freenode-staff due to inactivity, topic updated and locked to PDT home page)<br />
* <strike>[irc://irc.freenode.net/#virgo #virgo] - official channel for the [http://eclipse.org/virgo/ Virgo] project</strike> (dropped 25 September 2014)<br />
<br />
=== Related Channels ===<br />
* [irc://irc.freenode.net/#osgi #osgi] - OSGi related channel<br />
<br />
== More Info ==<br />
<br />
A [http://echelog.com/logs/browse/eclipse log] of the the traffic on #eclipse is available on the web. There is also an actively maintained [[IRC FAQ]] in which most questions eventually appear -- feel free to contribute! ''Much of the content was born [http://eclipsewiki.editme.com/IrcFaq here].''<br />
<br />
If you are a committer on an eclipse project, then you can get yourself a developer cloak. A developer cloak identifies you as a committer on the Eclipse project, gives you some privileges on the channel and masks your hostname. If you would like a developer cloak, please contact '''paulweb515''' or '''nitind''' on IRC.<br />
<br />
=== How Do I Start Using IRC? ===<br />
<br />
* First, choose an IRC client (see [[#How Do I Choose An IRC Client? | below]]). <br />
* Then, read the [http://freenode.net/faq.shtml#nicksetup Freenode Setup FAQ].<br />
<br />
=== How Do I Choose An IRC Client? ===<br />
<br />
* If you are having trouble choosing an IRC client, try [http://chatzilla.hacksrus.com/ ChatZilla] which runs inside Firefox. [https://support.mozilla.org/en-US/kb/instant-messaging-and-chat Thunderbird] Konversation and xchat are also widely used options.<br />
* For GNOME you can try [http://www.smuxi.org/ Smuxi].<br />
* Or, if you're familiar with the IM client Gaim (now called [http://pidgin.im/pidgin/home/ Pidgin]), it also works great with IRC on both Windows and Linux. <br />
* Mac users, try [http://www.google.ca/search?q=mac+irc+client one of these].<br />
* Another choice is [http://www.eclipse.org/ecf ECF's IRC client], which runs as a view inside of Eclipse.<br />
* If you cannot connect due to firewall issues or prefer to not install anything, try http://webchat.freenode.net/ to connect via HTTP.<br />
<br />
=== OK, I'm Set Up, Now What? ===<br />
<br />
* Read the [[IRC_FAQ | FAQ]]. <br />
* Join a [[#Main Channels | channel]].<br />
* Post a question, or answer one.<br />
<br />
== Other Notes ==<br />
<nowiki><br />
Welcome! If you have a question, just ask, or take a look at our FAQ - http://wiki.eclipse.org/IRC_FAQ <br />
Try typing ~faq to see more FAQs! If you have errors or logs to show, see ~pastebin. <br />
If you have screenshots to share, see ~image. If you need to describe your problem, please <br />
provide some ~info about your setup. Don't ask to ask, just ask, and please be patient when <br />
waiting for a response. Lurk. Thank you and enjoy your stay.<br />
</nowiki></div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/New_and_Noteworthy/4.7&diff=415790EGit/New and Noteworthy/4.72017-04-08T21:38:36Z<p>Michael.keppler.gmx.de: fixed formatting</p>
<hr />
<div>= EGit =<br />
==Features==<br />
*Sort branches by name in ref content assist<br />
*Fetch from Gerrit: checkout branch after resolving checkout conflicts<br />
*Prevent creation of invalid git config keys<br />
*Don't use 3 way compare if the common ancestor is same as one side<br />
*Added branch normalizer to branch rename dialog<br />
*Normalize the branch name in the CreateBranchWizard<br />
*Enable importing multiple projects from working tree<br />
*Improve sorting of FileDiffs<br />
*Staging view should react on editor activation<br />
*Improve reporting from background fetch and push jobs<br />
*Remove double border of CommitMessageArea in staging view<br />
*Give the PushResultDialog an image.<br />
*Display logical line numbers in DiffEditorPage<br />
*Provide a way to configure RepositoryChangeScanner interval<br />
*RepositoryChangeScanner should not query all repos if UI is not active<br />
<br />
==Cleanup==<br />
*Cleanup progress monitor management throughout EGit<br />
*Cleanup duplicate code: Unify saving in preference pages<br />
*Cleanup duplicate code: Unify pattern creation for content assist<br />
*Cleanup duplicate code: Unify scheduling of merge jobs<br />
*Cleanup duplicate code: Unify branch/ref content assist handling<br />
*Cleanup of defaultHandlers<br />
<br />
==Build and Release Engineering==<br />
*Upgrade maven plugins<br />
*Update target platform to jetty 9.3.17.v20170317<br />
*Update com.jcraft.jsch to 0.1.54<br />
*Update build to use Tycho 1.0.0<br />
*Add missing dependency to org.slf4j to org.eclipse.egit.ui<br />
*Update Orbit to S20170306214312 <br />
*Add org.eclipse.jgit.junit feature to test classpath of ui tests<br />
<br />
= Bug Fixes =<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?resolution=FIXED&resolution=DUPLICATE&classification=Technology&list_id=10006180&order=Importance&product=EGit&query_format=advanced&target_milestone=4.7 18 Bugs and 2 enhancement requests] were closed<br />
<br />
= Contributors =<br />
The following 10 developers worked on this release:<br />
<br />
Andrey Loskutov,<br />
David Weiser,<br />
David Pursehouse,<br />
Jaxsun McCarthy Huggan,<br />
Matthias Sohn,<br />
Michael Keppler,<br />
Ralf M Petter,<br />
Simon Delisle,<br />
Thomas Wolf,<br />
Wim Jongman</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Eclipse_Oomph_Authoring&diff=407381Eclipse Oomph Authoring2016-06-26T05:14:43Z<p>Michael.keppler.gmx.de: /* Testing the Setup Model */ typo</p>
<hr />
<div>== Getting Started ==<br />
<br />
=== What is Oomph? ===<br />
<br />
Please read [[Eclipse Installer]].<br />
<br />
<br />
=== Installing Oomph ===<br />
<br />
# Download and install the Eclipse '''Installer''' as outlined in [[Eclipse Installer]].<br />
# Make sure that the Oomph setup '''SDK''' is installed in your IDE. Either:<br />
## That's already the case because your IDE is a Mars M5 or later Eclipse Package, or<br />
## Start the installer and install an IDE of your choice (select on the first installer page), or<br />
## Use p2 to install "Oomph Setup SDK" from [http://download.eclipse.org/oomph/updates/latest http://download.eclipse.org/oomph/updates/latest].<br />
<br />
== Creating a Setup Project Model ==<br />
<br />
=== Using the Setup Project Model Wizard ===<br />
<br />
# Create an empty project in your workspace or select a folder in an existing project. You'll create the new "Setup Project Model" in the selected folder.<br />
# Open the New... dialog and select the "Setup Project Model" wizard:<br>[[Image:new-wizard.png]]<br><br />
# Select one of the provided templates (e.g., Eclipse.org, Github.com, or Simple) and adjust the displayed values:<br>[[Image:new-wizard-2.png]]<br><br />
# Some values are automatically derived from your input to fields '''higher up'''.<br />
# Open the Preview>>> to understand the impact of changes to the current field.<br />
<br />
=== Using the Setup Editor ===<br />
<br />
# Open the resulting setup file with Oomph's Setup Editor:<br>[[Image:setup-edit.png]]<br><br />
# Configure the tasks in the Properties view. Note that there are "Expert" properties available.<br />
# Add setup tasks to your project and/or to your project streams and configure them, too.<br />
# The Outline view displays a ''preview'' of the executable model with resolved variables.<br />
<br />
=== Testing the Setup Model ===<br />
<br />
# To test/execute your new setup model:<br />
## Start the installer and, if necessary, switch to the Advanced Mode via the dialog menu.<br />
## Pick any product on page 1 and click the Next button to proceed to page 2.<br />
## Drag and drop your <tt>.setup</tt> file onto one of the top-level catalogs (<tt>Eclipse.org</tt> or <tt>Github.com</tt>) in the projects tree. Your project will appear as a subproject of the special <tt>&lt;User&gt;</tt> project.<br />
## Double-click your project to add it to the table at the bottom of the page. There you can select a project stream in the Stream column. Press the Next button to proceed to the Variables page.<br />
## Fill in the empty fields and press the Next button to proceed to the Confirmation page.<br />
## Click Finish to start the installation process. The installer will first bootstrap a new IDE and then launch it to complete the installation at startup time.<br><br />
# Chances are that your first model contains errors. Always turn on live validation in the Setup editor to get early feedback. If the installation fails early and the new IDE doesn't come up go back to [[#Using the Setup Editor|Using the Setup Editor]]. If the IDE comes up but the initial configuration fails continue with step 3.<br />
# In the new IDE (whether the initial configuration was successful or not) open your model file from the main menu, Navigate &rarr; Open Setup &rarr; [[Image:branch.png]]. Find the problems and fix them. Then start the setup process '''from within''' this IDE via the main menu, Help &rarr; [[Image:update.png]] Perform Setup Tasks&hellip;. This "manual trigger" will pop up a confirmation dialog before starting the setup process so that you can review what tasks are scheduled for execution.<br />
<br />
=== Contributing to a Project Catalog ===<br />
<br />
When you are done authoring your model file (including testing the installation) commit/push it to the master branch of one of your '''Eclipse''' Git repositories. Find the ''plain URL'' of this file in [http://git.eclipse.org/c http://git.eclipse.org/c] and [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Oomph&component=Setup&bug_severity=enhancement&short_desc=Please%20include%20setup%20for%20project%20Xyz submit] a bugzilla asking for the inclusion of your model into the main index. Paste the Git plain URL of your model into the bug description.<br />
<br />
The same can be done if your project is not an Eclipse project, but hosted on '''GitHub'''. Simply state this fact in the bug description and paste the "raw" content URL to the file instead.<br />
<br />
== Understanding the Setup Engine ==<br />
<br />
=== Understanding Setup Tasks and Scopes ===<br />
<br />
The setup engine collects the '''setup tasks''' that are needed for a particular installation from a number of places called '''scopes'''. Some scopes can be nested and nested scopes generally ''inherit'' the tasks of their parent scopes. A setup is fully described by the following ''local entry'' scopes:<br />
<br />
* The '''Installation''' scope is located in <tt>eclipse/configuration/org.eclipse.oomph.setup/installation.setup</tt> and contains tasks that are specific to this installation. In addition (and more importantly) the Installation scope ''points'' to exactly one Product Version scope (see below) in order to make all tasks (including inherited tasks) of that product version apply to this installation, too.<br />
<br />
* The '''Workspace''' scope is located in <tt>workspace/.metadata/.plugins/org.eclipse.oomph.setup/workspace.setup</tt> and contains tasks that are specific to this workspace. In addition the Workspace scope can optionally ''point'' to a number of Stream scopes (see below) in order to make all tasks (including inherited tasks) of those streams apply to this workspace, too.<br />
<br />
* The '''User''' scope is located in <tt>user.home/.eclipse/org.eclipse.oomph.setup/setups/user.setup</tt> and contains tasks that are common to '''all''' installations and workspaces (unless they're restricted to particular installations or workspaces).<br />
<br />
<br />
The following additional scope types exist, so they can be referenced by the entry scopes:<br />
<br />
* The '''[http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/org.eclipse.setup Catalog Index]''' is the root scope and contains nested Product Catalogs and Project Catalogs.<br />
<br />
* A '''[http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/org.eclipse.products.setup Product Catalog]''' contains nested Product scopes and possibly a small number of tasks that are common to all nested scopes. Nested products may be contained directly or be linked in from separate files.<br />
<br />
* A '''[http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/OomphInstaller.setup Product]''' contains nested Product Version scopes and possibly some tasks that are common to all nested scopes.<br />
<br />
* A '''Product Version''' contains no nested scopes but tasks that are specific to that product version.<br />
<br />
* A '''[http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/org.eclipse.projects.setup Project Catalog]''' contains nested Project scopes and possibly a small number of tasks that are common to all nested scopes. Nested projects may be contained directly or be linked in from separate files.<br />
<br />
* A '''[http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/Oomph.setup Project]''' contains nested Stream and/or (Sub-) Project scopes and typically some tasks that are common to all nested scopes.<br />
<br />
* A '''Stream''' contains no nested scopes but tasks that are specific to that stream.<br />
<br />
<br />
The resulting list of tasks is then flattened, that is, compound tasks (folders) are recursively replaced by their contained tasks. Disabled tasks (see the editors context menu) are removed from the list. Tasks that are restricted to scopes that are not chosen for the current installation/workspace are also removed. Tasks that are excluded from the current ''trigger'' (one of Bootstrap, Startup or Manual) are also removed.<br />
<br />
The remaining list is then partially reordered according to a number of criteria such as task priority (hardcoded), variable references or explicitly authored task requirements (successors and predecessors in the expert properties). If no such criteria apply the tasks are kept in their authored order as much as possible.<br />
<br />
Some types of tasks allow only one instance in the list of tasks. For example only one variable task (see below) with a given variable name is allowed to execute. To specify several of them (with the same name) is perfectly okay, but you should notice that the earlier (according to the established order; see above) tasks are replaced/overridden by the later ones. This way, for example, a user can always override such tasks from any high/early scope, e.g., the Project or Stream scope, in his local User scope.<br />
<br />
Now variable references in all String attributes of the tasks and their child elements are resolved and replaced by their expanded values. For details see [[#Declaring_and_Using_Variables|Declaring and Using Variables]] below.<br />
<br />
Then the engine calls the isNeeded() method on each task in the list and removes those that are not needed (possibly according to the state of the running IDE). <br />
<br />
If now the list of needed tasks is not empty a confirmation dialog is displayed and when the user presses Install the perform() method is called on that tasks. The progress of the installation process is then displayed in a progress dialog. The installation can be canceled at any point in time.<br />
<br />
=== Declaring and Using Variables ===<br />
<br />
Variables play a very important role in the execution process. While a project model can perfectly work without the declaration or use of variables the model is typically more flexible with them. A variable must always be declared with a ''Variable Task'' somewhere in the model. It '''must have''' a name and '''can have''' a value or a default value.<br />
<br />
If a variable is declared without a value a prompt dialog is displayed early in the execution process. The user can enter the missing variable values, which are then stored as variable tasks in the User scope (see above). These stored variable tasks are restricted to the scope that originally declared the variable. At execution time these User-scoped variable tasks override the respective variable tasks that you have declared in your project model.<br />
<br />
'''Important''': Prompted values of variables that are declared with the type PASSWORD are not stored in <tt>user.home/.eclipse/org.eclipse.oomph.setup/setups/user.setup</tt> but rather in an Equinox Secure Storage node. The setup framework ensures that they are never shown in the user interface.<br />
<br />
You can use variables (refer to them) in any String-typed or URI-typed attribute of your model. The general syntax is:<br />
<br />
${''variable-name''}<br />
<br />
To prevent a variable reference from being expanded (e.g. you actually want to have the value '${var}' and not the value of "var"), you need to escape the variable syntax with an extra double dollar character. So "$${var}" will result in "${var}".<br />
<br />
In addition to the variables that are declared by VariableTasks you can refer to all of the following:<br />
<br />
* Attribute values of setup tasks with a defined ID. The reference syntax is ${''taskID''.''attributeName''}.<br />
* System properties as returned by <tt>System.getProperties()</tt><br />
* Environment variables as returned by <tt>System.getenv()</tt><br />
* Predefined variables as determined by the setup engine from the user input to the installer (see below)<br />
<br />
<br />
The following variables are predefined by the setup engine:<br />
<br />
{| class="wikitable"<br />
| '''scope.installation.name''' || The value of the <em>name</em> attribute of the current installation scope. <br />
|-<br />
| '''scope.installation.label''' || The value of the <em>label</em> attribute of the current installation scope.<br />
|-<br />
| '''scope.installation.description''' || The value of the <em>description</em> attribute of the current installation scope.<br />
|-<br />
| '''scope.workspace.name''' || The value of the <em>name</em> attribute of the current workspace scope.<br />
|-<br />
| '''scope.workspace.label''' || The value of the <em>label</em> attribute of the current workspace scope.<br />
|-<br />
| '''scope.workspace.description''' || The value of the <em>description</em> attribute of the current workspace scope.<br />
|-<br />
| '''scope.user.name''' || The value of the <em>name</em> attribute of the current user scope.<br />
|-<br />
| '''scope.user.label''' || The value of the <em>label</em> attribute of the current user scope.<br />
|-<br />
| '''scope.user.description''' || The value of the <em>description</em> attribute of the current user scope.<br />
|-<br />
| '''scope.product.catalog.name''' || The value of the <em>name</em> attribute of the current product catalog scope.<br />
|-<br />
| '''scope.product.catalog.label''' || The value of the <em>label</em> attribute of the current product catalog scope.<br />
|-<br />
| '''scope.product.catalog.description''' || The value of the <em>description</em> attribute of the current product catalog scope.<br />
|-<br />
| '''scope.product.name''' || The value of the <em>name</em> attribute of the current product scope.<br />
|-<br />
| '''scope.product.name.qualified''' || The concatenated value of the <em>name</em> attributes of the current product scope and its parent scopes.<br />
|-<br />
| '''scope.product.label''' || The value of the <em>label</em> attribute of the current product scope.<br />
|-<br />
| '''scope.product.description''' || The value of the <em>description</em> attribute of the current product scope.<br />
|-<br />
| '''scope.product.version.name''' || The value of the <em>name</em> attribute of the current product version scope.<br />
|-<br />
| '''scope.product.version.name.qualified''' || The concatenated value of the <em>name</em> attributes of the current product version scope and its parent scopes.<br />
|-<br />
| '''scope.product.version.label''' || The value of the <em>label</em> attribute of the current product version scope.<br />
|-<br />
| '''scope.product.version.description''' || The value of the <em>description</em> attribute of the current installation scope.<br />
|-<br />
| '''scope.project.catalog.name''' || The value of the <em>name</em> attribute of the current project catalog scope.<br />
|-<br />
| '''scope.project.catalog.label''' || The value of the <em>label</em> attribute of the current project catalog scope.<br />
|-<br />
| '''scope.project.catalog.description''' || The value of the <em>description</em> attribute of the current project catalog scope.<br />
|-<br />
| '''scope.project.name''' || The value of the <em>name</em> attribute of the current project scope.<br />
|-<br />
| '''scope.project.name.qualified''' || The concatenated value of the <em>name</em> attributes of the current project scope and its parent scopes.<br />
|-<br />
| '''scope.project.label''' || The value of the <em>name</em> attribute of the current project scope.<br />
|-<br />
| '''scope.project.description''' || The value of the <em>name</em> attribute of the current project scope.<br />
|-<br />
| '''scope.project.stream.name''' || The value of the <em>name</em> attribute of the current stream scope.<br />
|-<br />
| '''scope.project.stream.name.qualified''' || The concatenated value of the <em>name</em> attributes of the current stream scope and its parent scopes.<br />
|-<br />
| '''scope.project.stream.label''' || The value of the <em>label</em> attribute of the current stream scope.<br />
|-<br />
| '''scope.project.stream.description''' || The value of the <em>description</em> attribute of the current stream scope.<br />
|}<br />
<br />
<br />
You can also extend variable references that evaluate to file system paths by adding a forward slash notation of the nested path '''before''' the closing brace. The advantage is that the full resulting path is formatted in the OS-specific form, e.g.:<br />
<br />
${installation.location/git/myproject} evaluates to C:\develop\installation1\git\myproject on Windows<br />
<br />
<br />
After the path extension part you can add filter calls with pipe symbols. Filter names are generally case-insensitive. Multiple filters can be chained. Example:<br />
<br />
${installation.location|uri}/git/myproject evaluates to file:/C:/develop/installation1/git/myproject<br />
<br />
<br />
The following filters are currently available:<br />
<br />
{| class="wikitable"<br />
| '''file''' || Converts a file: URI to an OS-specific file system path.<br />
|-<br />
| '''fileExtension''' || Extracts the file extension from a URI or a file system path.<br />
|-<br />
| '''path''' || Extracts the path segments from a URI.<br />
|-<br />
| '''basePath''' || Removes the last segment from a file system path.<br />
|-<br />
| '''lastSegment''' || Extracts the last segment from a file system path.<br />
|-<br />
| '''uri''' || Converts a file system path to a file: URI.<br />
|-<br />
| '''uriLastSegment''' || Extracts the last path segment from a hierarchical URI or the authority from an opaque URI.<br />
|-<br />
| '''canonical''' || Canonicalizes a file system path.<br />
|-<br />
| '''gitRepository''' || Extracts the name of the repository from a Git URI (excluding a possible .git suffix).<br />
|-<br />
| '''upper''' || Converts all characters of a String value to upper-case.<br />
|-<br />
| '''lower''' || Converts all characters of a String value to lower-case.<br />
|-<br />
| '''cap''' || Capitalizes the first word of a String value.<br />
|-<br />
| '''allCap''' || Capitalizes all words of a String value.<br />
|-<br />
| '''camel''' || Converts a qualified name to camel case notation.<br />
|-<br />
| '''qualifiedName''' || Converts a camel case String value name to a qualified name.<br />
|-<br />
| '''preferenceNode''' || Escapes all forward slashes (/) of a String value, so that the result can be used as a value in preference nodes.<br />
|-<br />
| '''property''' || Escapes all double back slashes (\\) of a String value, so that the result can be used as a value in properties.<br />
|-<br />
| '''username''' || Escapes all "at" symbols (@) of a String value, so that the result can be used in URI that contain a username.<br />
|-<br />
| '''length''' || Converts a String to a String that contains the alpha-numerical representation of the length of the original String.<br />
|-<br />
| '''trim''' || Removes all whitespace from the beginning and the end of a String.<br />
|-<br />
| '''trimLeft''' || Removes all whitespace from the beginning of a String.<br />
|-<br />
| '''trimRight''' || Removes all whitespace from the end of a String.<br />
|-<br />
| '''trimTrailingSlashes''' || Removes all slashes and backslashes from the end of a String.<br />
|}<br />
<br />
<br />
When looking for declared variables that you can use in your model also have a look at the Outline view that displays variables from the outer scopes. For example the current [http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/org.eclipse.projects.setup Project Catalog] file for Eclipse.org projects contains declarations for some useful variables:<br />
<br />
* '''jre.location-1.4''' --> The folder containing a 1.4 compatible JDK/JRE for architecture ${os.arch}<br />
* '''jre.location-1.5''' --> The folder containing a 1.5 compatible JDK/JRE for architecture ${os.arch}<br />
* '''jre.location-1.6''' --> The folder containing a 1.6 compatible JDK/JRE for architecture ${os.arch}<br />
* '''jre.location-1.7''' --> The folder containing a 1.7 compatible JDK/JRE for architecture ${os.arch}<br />
* '''jre.location-1.8''' --> The folder containing a 1.8 compatible JDK/JRE for architecture ${os.arch}<br />
* '''git.user.id''' --> The Eclipse user ID for Git/Gerrit commits<br />
* '''git.author.name''' --> The Eclipse author name for Git/Gerrit commits<br />
* '''git.author.email''' --> The Eclipse author email for Git/Gerrit commits<br />
* '''bugzilla.id''' --> The Eclipse user ID for Bugzilla/Hudson<br />
* '''eclipse.user.password''' --> The Eclipse password for Bugzilla/Hudson<br />
<br />
<br />
The advantage of having these variables be declared in a project-independent scope is that their prompted values will be stored in the User scope without a project restriction. Hence users will not be required to enter these values more than once even when they install additional environments. Of course they can be edited in the User model at any time.<br />
<br />
The recommended form of variable names is the dot-separated notation. Note that it is typically not possible to define environment variables with dots in their name. If you want to define variables in your process/system environment use underscores instead of the dots; you can still refer to them via dot-notation in your models.<br />
<br />
== Tips and Tricks ==<br />
<br />
=== Getting Early Feedback ===<br />
Why didn't the model editor tell me earlier that I've made a silly mistake?<br />
Please enable Live Validation in the editor menu to get early feedback.<br />
<br />
=== Copying Tasks and Other Elements ===<br />
The Setup Editor supports the export and import of any model elements by using copy to or paste from the clipboard. The clipboard will/must contain a valid XML document. With this method, for example, you can easily copy task snippets from your model directly into a forum post when you ask for help (or into a Skype window when you chat with your collegues). Or you can easily paste such XML snippets from forum replies directly into your Setup Editor.<br />
<br />
You have access to many example setups from within your IDE! Use Navigate->Open Setup->Parent Models->Open Catalog Index to investigate everything within the index. The context menu provides a way to open elements in a text editor. This is particularly handy for finding out where a particular setup is hosted (hrefs are resolved in the Setup editor) - one use case is checking and repairing links to project setups added to your user projects.<br />
<br />
=== Hosting your own index / catalogs ===<br />
If you want to host your own product or project catalog, you must provide a URI mapping to the installer to locate the root setup file (the "index"). Open the eclipse.ini file and add an oomph.redirection.<some_id> where some_id is any unique identifier. The root EMF model is an Index and must be stored in the file '''org.eclipse.setup'''. Use http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/org.eclipse.setup as a starting point. All of your other setup models can be stored in any file name you desire. You must also copy all of the model files in http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/ to your redirection <path>/models/<br />
<br />
-Doomph.redirection.setups=<nowiki>http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/->http://<hostname>/<path>/</nowiki><br />
<br />
The source URI may be abbreviated to <nowiki>index:/</nowiki> and the target URI may also be a file URI, e.g. on a shared file server.<br />
<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=481580 Bug 481580] has introduced empty redirectable catalogs for products ('''redirectable.products.setup''') and projects ('''redirectable.projects.setup''') to the Oomph index. These allow providing your own catalogs without replacing the entire index or disabling the catalogs shipped with Oomph (by redirecting them). The following steps are necessary to make use of those setups.<br />
* Create your own catalog setup file. Project setups should be referenced using absolute URIs only, otherwise redirection will become very messy.<br />
* Add a redirection task as described above to the eclipse.ini file (e.g. '''-Doomph.redirection.myProjectCatalog=index:/redirectable.projects.setup->...''').<br />
* Your catalog setup file must contain an EclipseIni task creating the same redirection! Otherwise your catalog will not be visible in the Eclipse created by the installer and hence the projects selected from it cannot be installed.<br />
* The first time, you may have to enable your new catalog by selecting it in the folders icon of the drop-down in the upper right hand corner of the wizard's Projects page, otherwise it will be invisible.<br />
<br />
To debug the processing of -Doomph.redirection.* if needed, set a breakpoint in org.eclipse.oomph.setup.internal.core.util.SetupCoreUtil.configureResourceSet(ResourceSet) within if (((String)key).startsWith(SetupProperties.PROP_REDIRECTION_BASE)).<br />
<br />
=== Shipping your own index ===<br />
If you want to include your own product or project catalog, you may ship the root setup file (the "index") relative to the installer directory. Then you can redirect the index as explained in [[#Hosting your own index / catalogs| Hosting your own index / catalogs]]. For example, you can place all setup files in an eclipse-installer/setups/ folder and then redirect access to it with a relative target URI:<br />
<br />
-Doomph.redirection.setups=<nowiki>http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/->setups/</nowiki><br />
<br />
Note that shipping the index rather than maintaining it in a central location (accessible to all parties interested) has the following disadvantage. As each user has her own copy of the index, updates in the setup files will not be distributed automatically.<br />
<br />
=== Generating PDE Target Definition files (*.target) and their use by Tycho ===<br />
<br />
Oomph can automagically generate a *.target files compatible with the PDE target definition file format (*.target) for you from your *.setup model. This is particularly useful if used in combination with Tycho's support for them, see https://wiki.eclipse.org/Tycho/Target_Platform, as it allows you to maintain p2 Repositories and Requirements in one single place, and have that be used both for workspace set-up and builds. <br />
<br />
To generate a *.target file, add an Annotation similar to the example found in Oomph's own setup model (see here http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/tree/setups/Oomph.setup), like so:<br />
<br />
<annotation<br />
source="http:/www.eclipse.org/oomph/targlets/TargetDefinitionGenerator"><br />
<detail<br />
key="location"><br />
<value>${git.clone.location}/targetdefinition/DesignStudio.target</value><br />
</detail><br />
<detail<br />
key="extraUnits"><br />
<value>org.eclipse.equinox.executable.feature.group</value><br />
</detail><br />
<detail<br />
key="includeAllPlatforms"><br />
<value>false</value><br />
</detail><br />
<detail<br />
key="includeSource"><br />
<value>true</value><br />
</detail><br />
<detail<br />
key="generateVersions"><br />
<value>true</value><br />
</detail><br />
</annotation><br />
<br />
Note that the *.target file will be updated (or initially generated if first time) each time that Oomph Performs Setup Tasks (and not every time you only "touch" your *.setup model). Any errors encountered while generating the *.target file are reported in the Setup Log as usual.<br />
<br />
''TODO Document what preferredRepositories, PomModulesUpdater & PomArtifactUpdater do...''<br />
<br />
=== Setting up WST Server Runtime and Instances in your Project Setup ===<br />
<br />
==== Server Runtime Preference ====<br />
<br />
1. Use an oomphed installation/workspace with preference recorder enabled.<br />
<br />
2. Open your project and user setup editors.<br />
<br />
3. Go to Preferences / Server / Runtime Environments and 'Add' it as usual.<br />
<br />
4. Drag the selected '/instance/org.eclipse.wst.server.core/runtimes' from user to project setup.<br />
<br />
==== Server Instance in Servers View ====<br />
Requires server runtime to be setup first.<br />
<br />
1. Open Servers View and create New server instance and deploy webapps as usual<br />
<br />
2. Optionally open server instance editor and adapt configuration as usual.<br />
<br />
3. Close Eclipse.<br />
<br />
4. Start it again.<br />
<br />
5. Open '.plugins/org.eclipse.wst.server.core/servers.xml' from your workspace/.metadata using a UTF capable editor<br />
<br />
6. Add Resource Creation Task to your project setup:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<setup:ResourceCreationTask<br />
xmi:version="2.0"<br />
xmlns:xmi="http://www.omg.org/XMI"<br />
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"<br />
content="PUT_CONTENT_FROM_SERVERS_XML_INTO_HERE_USING_A_UTF_CAPABLE_EDITOR_AND_OOMPH_DIALOG"<br />
targetURL="${workspace.location|uri}/.metadata/.plugins/org.eclipse.wst.server.core/servers.xml"<br />
encoding="UTF-8"><br />
<description>tomcat server integration</description><br />
</setup:ResourceCreationTask><br />
<br />
7. Use the resource task content dialog to put the servers xml content into the task.<br />
<br />
8. Copy "Servers" project from this workspace into a suitable location of your branch checkout and add/commit/push.<br />
<br />
9. Setup project import task that can pick the Servers project up from that committed location.<br />
<br />
That's it. If you want to share it among fellows, be sure to agree on canonical paths for your server installations.<br />
<br />
=== Suppress prompt for default workspace already upon very first start ===<br />
<br />
Adjust the SHOW_WORKSPACE_SELECTION_DIALOG property to false via configuration settings org.eclipse.ui.ide.prefs ...<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<setup:ResourceCreationTask<br />
xmi:version="2.0"<br />
xmlns:xmi="http://www.omg.org/XMI"<br />
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"<br />
excludedTriggers="STARTUP MANUAL"<br />
content="MAX_RECENT_WORKSPACES=5&amp;#xD;&amp;#xA;RECENT_WORKSPACES=${workspace.location|property}&amp;#xD;&amp;#xA;RECENT_WORKSPACES_PROTOCOL=3&amp;#xD;&amp;#xA;SHOW_WORKSPACE_SELECTION_DIALOG=false&amp;#xD;&amp;#xA;eclipse.preferences.version=1"<br />
targetURL="configuration:/.settings/org.eclipse.ui.ide.prefs"<br />
encoding="UTF-8"/><br />
<br />
=== Open default perspective already upon very first start ===<br />
Examples below using Perspective ID for Java perspective.<br />
<br />
Tell Eclipse which perspective to open initially, by adding option to eclipse ini:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<setup:EclipseIniTask<br />
xmi:version="2.0"<br />
xmlns:xmi="http://www.omg.org/XMI"<br />
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"<br />
excludedTriggers="STARTUP"<br />
option="-perspective"<br />
value="org.eclipse.jdt.ui.JavaPerspective"/><br />
<br />
Setting a perspective to be default, by adding preference task:<br />
<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<setup:PreferenceTask<br />
xmi:version="2.0"<br />
xmlns:xmi="http://www.omg.org/XMI"<br />
xmlns:setup="http://www.eclipse.org/oomph/setup/1.0"<br />
key="/instance/org.eclipse.ui/defaultPerspectiveId"<br />
value="org.eclipse.jdt.ui.JavaPerspective"/><br />
<br />
=== How to switch the current stream ===<br />
<br />
If you would like to switch the current stream/s, you can re-use Oomph's initial "Eclipse Importer" wizard, available as "Import Projects..." in the drop-down of the Perform Setup Tasks reload action in the Oomph toolbar, or via the menu File > Import> Oomph > Projects into Workspace.<br />
<br />
Note that it is currently not yet possible to remove the "current" project stream. As a workaround, use menu Navigate > Open Setup > Open Workspace (or if visible click the 'blue guy' icon in the Oomph toolbar) to Open Workspace workspace.setup, expand the first node, click on the Workspace entry, open Properties view, and change the last property named "Streams" and remove the current stream.<br />
<br />
Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=476434 enhancement may make this easier in the future.<br />
<br />
<br />
=== How to install Eclipse plugins using the P2 Director and Repository Explorer ===<br />
<br />
Oomph can install Eclipse plugins which you require. This also works for normal Java Projects set up models, not just for Eclipse plug in OSGi development, and is handy to install commonly used 3rd-party Eclipse plugins which are not all available from eclipse.org p2 sites (think e.g. http://eclemma.org). Here's how:<br />
<br />
1. add a P2 Director child task to your *.setup, if it doesn't already have one<br />
<br />
2. add a Repository child in your P2 Director task<br />
<br />
3. in the Properties of the Repository set the URL to a valid p2 repo (e.g. http://update.eclemma.org)<br />
<br />
4. right-click that Repository and choose Explore, to open the Repository Explorer view<br />
<br />
5. in the Repository Explorer view change to [X] Compatible and (*) Minor at the lower-right hand corner<br />
<br />
6. drag & drop the version from the Repository Explorer view into the P2 Director task of your *.setup editor, to create a Requirement child<br />
<br />
Drag & Drop should normally work, but appears to be broken at least on Neon Milestone 6 on Linux; in that case:<br />
<br />
6. manually create a new child Requirement inside the P2 Director task<br />
<br />
7. in the Repository Explorer view use the brown (C) icon to switch to Expert Mode to see IDs instead of names<br />
<br />
8. find the ID of the feature IU, it's the one with a PDE feature + folder kind of icon, often ending in (feature.)feature.group<br />
<br />
9. in the Properties of the Requirement, type the Name to the ID found above (e.g. com.mountainminds.eclemma.feature.feature.group)<br />
<br />
10. in the Properties of the Requirement, Type should have automatically switched to Feature<br />
<br />
PS: If you are looking for the URL of p2 repos to pre-install some of the the M2E connectors, see https://git.eclipse.org/c/m2e/m2e-discovery-catalog.git/tree/org.eclipse.m2e.discovery.oss/connectors.xml<br />
<br />
<br />
<br />
=== How to create M2E lifecycle-mapping-metadata.xml to avoid littering your pom.xml with org.eclipse.m2e:lifecycle-mapping ===<br />
<br />
Read https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html & https://wiki.eclipse.org/M2E_compatible_maven_plugins and apply as follows:<br />
<br />
<setupTask<br />
xsi:type="setup:PreferenceTask"<br />
key="/instance/org.eclipse.m2e.core/eclipse.m2.WorkspacelifecycleMappingsLocation"<br />
value="${workspace.location}/.metadata/.plugins/org.eclipse.m2e.core/lifecycle-mapping-metadata.xml"/><br />
<br />
<setupTask<br />
xsi:type="setup:ResourceCreationTask"<br />
content="..."<br />
targetURL="${workspace.location|uri}/.metadata/.plugins/org.eclipse.m2e.core/lifecycle-mapping-metadata.xml"<br />
encoding="UTF-8"><br />
<description>Initialize M2E's Maven Lifecycle Mappings, see https://www.eclipse.org/m2e/documentation/m2e-execution-not-covered.html &amp; https://wiki.eclipse.org/M2E_compatible_maven_plugins</description><br />
</setupTask><br />
<br />
For "content" just open the popup using the [...] icon in the Properties and copy/paste the content from menu Window > Preferences > Maven > Lifecycle Mappings: Open workspace lifecycle mappings metadata. (This is easier than editing the content=".." in source view, because it will correctly do the XML escaping for you.)<br />
<br />
Now whenever M2E whines about stuff like "Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-dependency-plugin:2.10:unpack (execution: unpack-license, phase: generate-resources)" etc. just use the Quick Fix in the Problems view and choose the option to use workspace preferences (instead of letting the quick fix modify your pom.xml to add org.eclipse.m2e:lifecycle-mapping <lifecycleMappingMetadata>).<br />
<br />
<br />
=== How to automatically pre-enable Gerrit ===<br />
<br />
If you would like to save your end-users from having to [[EGit/User_Guide#Enabling_Gerrit_for_a_repository|manually enabling Gerrit for a repository in EGit]], then you can use the follow magic variable which Oomph will recognize and act upon:<br />
<br />
<setupTask<br />
xsi:type="setup:VariableTask"<br />
name="YOURORG.gerrit.uri.pattern"<br />
value="(https|ssh)://([^@/]+@)?(git.YOURORG.org:29418/.*|git.YOURORG.org/gerrit/.*)"/><br />
<br />
=== How to find a P2 repository at Eclipse using the Repository Explorer ===<br />
<br />
Most projects don't document the locations of all their p2 update sites very well. This makes it hard to find the URL you need in order to install something or in order to specify a URL for your target platform definition. Oomph indexes all the p2 update sites available at download.eclipse.org to make this job easier. You can make use of this as follows:<br />
<br />
# In the Quick Access control, type "Repository Explorer" to show Oomph's Repository Explorer view.<br />
# In that view's toolbar, locate the tool item with the hover "Search Eclipse repositories by provided capabilities", i.e., the one that looks like a little search flashlight, and click it.<br />
# This brings up the "Eclipse Repository Search" dialog. The index is very large so it takes a while to load it. But it's cached locally and updated on the server once per day.<br />
# At the root of the displayed tree are p2's namespaces and under each of these are the capabilities in that namespace. They're organized hierarchically by their qualified name. It's all quite technical and the tree is very large. So while you can explore it, you'll most likely want to use the filter to find something quickly.<br />
# Type the fully qualified name of a Java package or installable unit you wish to locate into the filter. Note that tree items for which there exist a concrete version in some repository are decorated as such. Keep in mind that many projects don't version their Java packages, so it's often better to look at the org.eclipse.equinox.p2.iu category. Here's what it looks like searching for "org.eclipse.emf.ecore.xcore":<br>[[File:SearchEclipseRepositoryDialog.png]]<br><br />
# You can select a capability in the tree so that the lower panel displays all the versions of the capability that are available. Under each of those are nested the update sites that contain them. Composite update sites show their children hierarchically.<br />
# Of course you can double click a repository to further explore its contents in the Repository Explorer itself.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=404430EGit/Contributor Guide2016-04-26T06:41:31Z<p>Michael.keppler.gmx.de: /* Commit message guidelines */ case sensitive bug footer</p>
<hr />
<div>= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[http://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Obtaining Sources =<br />
<br />
EGit and JGit are self hosted in Git. You can browse the repositories on the web: <br />
[http://git.eclipse.org/c/egit/ EGit], [http://git.eclipse.org/c/jgit/ JGit]<br />
<br />
The first section below describes how to clone a repository and can be skipped if you have done this before.<br />
<br />
The next section lists the repositories and their URLs.<br />
<br />
== Cloning ==<br />
<br />
=== On the command line ===<br />
<br />
<pre style="width: 40em;"><br />
git clone <enter URL><br />
</pre><br />
<br />
After that, import the projects into Eclipse using Import > Existing Projects into Workspace.<br />
<br />
=== Using EGit (see [http://www.eclipse.org/egit/download/ download page]) ===<br />
<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
Then, clone the repository and import the projects:<br />
<br />
* Open ''File'' &gt; ''Import...'' and select ''Git'' > ''Projects from Git''<br />
* Selet ''URI''<br />
* Enter the URL (see next section) <br />
* Import existing projects into the workspace from the newly created working directory<br />
<br />
== Repositories ==<br />
<br />
To develop EGit, the EGit and JGit repositories are needed, the others are optional. To develop JGit, only JGit is needed. <br />
<br />
=== EGit ===<br />
<br />
URL: https://git.eclipse.org/r/egit/egit.git<br />
<br />
This is the main repository, where the standard EGit feature is developed. It contains the code for the UI and Eclipse integration.<br />
<br />
=== JGit ===<br />
<br />
URL: https://git.eclipse.org/r/jgit/jgit.git<br />
<br />
This is the Java implementation of Git used by EGit, for working with Git repositories.<br />
<br />
=== EGit GitHub Integration ===<br />
<br />
URL: https://git.eclipse.org/r/p/egit/egit-github.git<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
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''.<br />
<br />
=== EGit PDE Tools ===<br />
<br />
URL: https://git.eclipse.org/r/egit/egit-pde.git<br />
<br />
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. <br />
<br />
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 Git in your workspaces.<br />
<br />
= Development IDE Configuration =<br />
<br />
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:<br />
<br />
http://www.eclipse.org/downloads/<br />
<br />
== Tools ==<br />
<br />
'''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]).<br />
<br />
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:<br />
<br />
* File > Import > Install > Install Software Items from File<br />
* Browse...<br />
** Go to the location of your egit repository, open the ''tools'' directory and select ''egit-developer-tools.p2f''<br />
** Alternatively, if you only want to contribute to JGit, download the file from the above link and select it<br />
* All the items you don't already have should be selected automatically<br />
* Finish the wizard<br />
* Restart<br />
<br />
== Java Requirements ==<br />
<br />
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.<br />
<br />
We are using ''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 ''API Tools Environment Descriptions'' from the release train repository, see [[Execution_Environments#Installing_Execution_Environment_Descriptions|Installing Execution Environment Descriptions]].<br />
<br />
== Dependencies ==<br />
<br />
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.<br />
<br />
=== Option 1 (recommended): Use a Target Platform ===<br />
<br />
[[Image:EGit-Target-Platforms.png|right|EGit target platforms in org.eclipse.egit.target]]<br />
<br />
This is the easiest method to install dependencies:<br />
<br />
* Open the ''org.eclipse.egit.target'' project<br />
* 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)<br />
* 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)<br />
<br />
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,<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
=== Option 2: Install from Orbit P2 Repository ===<br />
<br />
Install the dependencies from the Orbit p2 repository by importing the p2f file described [[#Tools|above]].<br />
<br />
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:<br />
<br />
* Java Mocking and Stubbing Framework<br />
* Args4j<br />
* Protocol Buffers<br />
* Apache Jakarta log4j Plug-in<br />
* Apache Commons Compress<br />
* XZ Data Compression<br />
* Hamcrest Library of Matchers<br />
* JavaEWAH<br />
<br />
== Running ==<br />
<br />
Now that everything builds, the next step is to run an Eclipse instance with the EGit/JGit code of the workspace:<br />
<br />
* Right click on the ''org.eclipse.egit.ui'' project<br />
* Debug As &gt; Eclipse Application<br />
<br />
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.<br />
<br />
The launch configuration can also be used in normal (non-debug) mode of course.<br />
<br />
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 />
<br/><br />
<br />
= Builds =<br />
<br />
The central EGit and JGit builds run on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson instance]<br />
<br />
Prerequisites for the Maven build are<br />
* [http://maven.apache.org/download.html at least Maven 3.0.0] (but currently not Maven 3.1.0)<br />
* see [http://maven.apache.org/settings.html settings.xml reference] on how to do basic Maven configuration<br />
* if you want to learn how Maven works start reading [http://maven.apache.org/guides/getting-started/index.html the Maven Getting Started Guide]<br />
<br />
Hudson<br />
* [https://hudson.eclipse.org/egit/master development build jobs]<br />
* [https://hudson.eclipse.org/egit/stable maintenance and release build jobs]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven 2 or 3.<br />
* use Java 7 to run the JGit Maven build (required since bundle ''org.eclipse.jgit.java7'' needs Java 7)<br />
* JGit packaging projects (Eclipse feature and update site) are built using Maven 3 and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven 3 and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build Sequence ==<br />
* 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.<br />
* The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* To run the build behind a firewall follow http://maven.apache.org/guides/mini/guide-proxies.html <br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/org.eclipse.jgit.updatesite/target/site<br />
<br />
The hudson build on build.eclipse.org uses (for SNAPSHOT builds):<br />
[~/src/egit] $ mvn clean install -Djgit-site=https://repo.eclipse.org/content/unzip/snapshots.unzip/<br />
org/eclipse/jgit/org.eclipse.jgit.repository/${JGIT_VERSION}/org.eclipse.jgit.repository-${JGIT_VERSION}.zip-unzip/<br />
<br />
If you wan to build EGit for the specific Juno platform, consider using the <code>platform-juno</code> maven profile:<br />
[~/src/egit] $ mvn -P platform-juno clean install<br />
<br />
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.<br />
<br />
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.<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://hudson.eclipse.org/egit/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/findbugs EGit FindBugs Results]<br />
* [https://hudson.eclipse.org/egit/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Checking for JGit API Changes using API Baseline ==<br />
<br />
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:<br />
* 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<br />
* 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.<br />
* the API tools will then raise warning/errors for all detected problems and provide quick fixes helping to resolve these problems<br />
* see the [http://wiki.eclipse.org/PDE/API_Tools/User_Guide PDE API Tools User Guide] for more details.<br />
<br />
== Automated Signing and Publishing ==<br />
EGit and JGit builds running on the [https://hudson.eclipse.org/egit/ JGit/EGit Hudson] are automatically signed <br />
(using the [[Common_Build_Infrastructure#Signing_tool | CBI eclipse-jarsigner-plugin]]) and published to the folder<br />
<pre><br />
master branch: /home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
latest stable branch: /home/data/httpd/download.eclipse.org/egit/updates-stable-nightly<br />
</pre><br />
<br />
* 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/<br />
* 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.<br />
<br />
==== Signing (old method, replaced by automated procedure) ====<br />
<br />
To sign the EGit build, you need to have ssh access to build.eclipse.org and the ability to run '''/usr/bin/sign'''<br />
<br />
At the moment, Chris Aniszczyk (caniszczyk) and Matthias Sohn (msohn) have signing privileges.<br />
<br />
The first step is to ensure you're in a place you can sign on build.eclipse.org<br />
<br />
cd /home/data/httpd/download-staging.priv/commonBuild<br />
<br />
Next you run the signing command (Usage: /usr/bin/sign <file> <mail|nomail> [outputDir]) on a zip of the EGit repo...<br />
<br />
sign egit-p2-repo.zip my@email.com /home/data/users/caniszczyk/egit-0.8<br />
<br />
After that, you can publish the zip that is generated with the signing information.<br />
<br />
== Contribution to Release Train ==<br />
<br />
The release train contribution for JGit and EGit is maintained in the git repository <br />
<pre>ssh://git.eclipse.org/gitroot/simrel/org.eclipse.simrel.build.git</pre><br />
in the file<br />
<pre>egit.b3aggrcon</pre><br />
<br />
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 />
<br/><br />
<br />
= Documentation =<br />
== JGit ==<br />
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}.<br />
E.g. http://download.eclipse.org/jgit/site/3.5.0.201409260305-r/<br />
<br />
Generating the site:<br />
'''$ mvn site:site'''<br />
<br />
Staging the site locally under ./target/staging:<br />
'''$ mvn site:stage'''<br />
<br />
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:<br />
'''$ mvn site:deploy'''<br />
The site is deployed under http://download.eclipse.org/jgit/site/${project.version}<br />
<br />
To select the ssh key to use for deploying over ssh add the following section to your Maven settings.xml:<br />
<server><br />
<id>jgit.website</id><br />
<username>username</username><br />
<privateKey>${user.home}/.ssh/id_rsa</privateKey><br />
<filePermissions>664</filePermission><br />
<directoryPermissions>775</directoryPermissions><br />
<configuration></configuration><br />
</server><br />
<br />
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'''.<br />
<br />
If you uploaded the site for a new release update the index<br />
/home/data/httpd/download.eclipse.org/jgit/docs/latest/apidocs/index.html<br />
to refer to the new release's site.<br />
<br />
== EGit ==<br />
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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the test bundles'.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests in ''org.eclipse.jgit.http.test'' rely on the Jetty web container.<br />
<br />
To run these tests from Eclipse the Jetty feature is needed. Use one of the target platforms as described in [[#Dependencies|dependencies]].<br />
<br />
Alternatively, install "Jetty 9.2.10.v20150310" from http://download.eclipse.org/jetty/updates/jetty-bundles-9.x/9.2.10.v20150310/<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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''.<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, using the 'SWTBot for Eclipse Testing' feature.<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature":<br />
* http://download.eclipse.org/technology/swtbot/snapshots/<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== During Maven Build ===<br />
<br />
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].<br />
<br />
If you want to skip execution of UI tests (only execute core tests):<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
If you want to skip all tests:<br />
<br />
mvn clean install -Dmaven.test.skip=true<br />
<br />
== Auxilary testing tools ==<br />
<br />
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.<br />
<br />
= Bugs =<br />
<br />
If you are looking for bugs/enhancements to start contributing, they have the keyword "helpwanted" or "bugday":<br />
<br />
[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]<br />
<br />
[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]<br />
<br />
== Links ==<br />
=== Filing Bugs ===<br />
==== How to file bugs ==== <br />
*[[FAQ_How_do_I_report_a_bug_in_Eclipse%3F | How do I report a bug in Eclipse?]] <br />
*[https://bugs.eclipse.org/bugs/page.cgi?id=bug-writing.html Bug Writing Guidelines]<br />
*[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html How to Report Bugs Effectively] by Simon Tatham<br />
<br />
==== File a bug ====<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
* [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends (bugs and enhancements)<br />
!EGit <br />
!JGit<br />
|-<br />
|Open by component (date range editable)<br />
|[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] <br />
|[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]<br />
|-<br />
|Open by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=ASSIGNED Open]<br />
|-<br />
|Assigned <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned] <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|Open and closed by status <br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed target milestones</span> <br />
| [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]<br />
| [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]<br />
|-<br />
| Open bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open enhancements<br />
| [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]<br />
| [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]<br />
|-<br />
| Bugs with votes<br />
| [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]<br />
| [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]<br />
|-<br />
|Assigned bugs and enhancements <br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit bugs<br />
| 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]<br />
|-<br />
| New bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><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''.<br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in Git repositories which are configured for Gerrit code review.<br />
<br />
'''egit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTPS protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/egit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/egit.git'''<br />
* 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 />
'''jgit'''<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
* Select URL <br />
** HTTP protocol: '''https://git.eclipse.org/r/p/www.eclipse.org/jgit.git'''<br />
** SSH protocol: '''ssh://user@git.eclipse.org:29418/www.eclipse.org/jgit.git'''<br />
* 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 />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
== Using Gerrit at Eclipse ==<br />
<br />
EGit and JGit projects are using [http://code.google.com/p/gerrit/ Gerrit Code Review] for Git based patch submission and review. <br />
<br />
Parts of this chapter are also available in the [http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].<br />
<br />
=== User Account ===<br />
*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.<br />
<br />
=== Legal Paperwork ===<br />
<br />
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.<br />
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].<br />
<br />
Minimally, all Git commits you contribute must have the following:<br />
* A single line summary in the comment field, followed by a more detailed descriptive paragraph;<br />
* Your credentials (email address) captured in the "Author" field; and<br />
* A "Signed-off-by" entry with matching credentials in the comment.<br />
* 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].<br />
<br />
In addition ensure<br />
* 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.<br />
<br />
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.<br />
<br />
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:<br />
* If it's committed: git log --shortstat<br />
* If not committed: git diff --stat<br />
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.<br />
<br />
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)].<br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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.]<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit/egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit/jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[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].<br />
* Alternative approach: Add a new review remote in the Git Repositories view and select '''Gerrit Configuration...''' in the context menu of the remote<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** 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.<br />
* Instead of using the '''Gerrit Configuration...''' wizard you can do the configuration steps manually:<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** <code>ssh://username@git.eclipse.org:29418/(project).git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
<br />
*Visit our [https://git.eclipse.org/r/ Gerrit Code Review instance] to start reviewing<br />
<br />
=== Using the Mylyn Gerrit Connector ===<br />
The Mylyn Gerrit Connector can be installed from the Mylyn p2 repository, e.g. for juno from http://download.eclipse.org/mylyn/releases/juno.<br />
<br />
It contains several useful features:<br />
* Cloning from Gerrit and automatic configuration<br />
** 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.<br />
* Importing Gerrit changes as Mylyn tasks<br />
* Fetching patch sets directly from the task editor<br />
* Reviewing changes in the task editor<br />
* Submitting changes from the task editor<br />
<br />
== Granularity of Changes ==<br />
<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
<br />
=== Branches ===<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedence.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
=== Braces for one-line statements ===<br />
<br />
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.:<br />
<br />
if (condition)<br />
doSomething();<br />
<br />
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:<br />
<br />
if (condition) {<br />
doSomething();<br />
}<br />
<br />
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}}.<br />
<br />
=== Removing trailing whitespace ===<br />
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}}.<br />
<br />
As a workaround, use the following sequence of commands in the Java editor to trick the save action:<br />
* remove the offending trailing whitespace<br />
* the save action re-adds the trailing whitespace<br />
* CTRL-Z (CMD-Z on Mac) removes the re-added whitespace without triggering the save action again<br />
<br />
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.<br />
<br />
== Commit message guidelines ==<br />
<br />
*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.<br />
*The first line should be a clear and concise description about the change and should not end with a dot. <br />
*Enter a newline before providing a more detailed description about the change.<br />
*Format the commit message to have newline characters after every 60-70 characters. <br />
*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"]<br />
*''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.<br />
**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. Use exactly the capitalization "Bug", since the automatic linking mechanism to the bug database is case sensitive.<br />
**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<br />
**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''.<br />
**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.<br />
<br />
<pre>Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
CQ: 6031<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
== Copyright ==<br />
<br />
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.<br />
<br />
When there is only one copyright present (from a person or a company), like this:<br />
<br />
<pre>Copyright (C) 2010, 2011 Some Name <some@example.org><br />
</pre><br />
<br />
Change it like this (notice the updated year):<br />
<br />
<pre>Copyright (C) 2010, YEAR Some Name <some@example.org> and others.<br />
</pre><br />
<br />
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.<br />
<br />
When there are multiple copyright entries there, add yours as a separate line. So, given this:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
</pre><br />
<br />
Add another line:<br />
<br />
<pre>Copyright (C) 2010 Some Name <some@example.org><br />
Copyright (C) 2011 Other Name <other@example.org><br />
Copyright (C) YEAR Your Name <you@example.org><br />
</pre><br />
<br />
For new files, copy one of the existing headers and start the copyright section with your name.<br />
<br />
Also see http://www.eclipse.org/legal/copyrightandlicensenotice.php for more information.<br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
<br />
* Run all existing tests. It does not take very long.<br />
* 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.<br />
<br />
== Sending patches by mail ==<br />
<br />
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 [http://www.kernel.org/pub//software/scm/git/docs/git-send-email.html git send-email]. Instead, please use [http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html git format-patch] to generate the <code>mbox</code>, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides. <br />
<br />
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. <br />
<br />
'''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 />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_dedicated_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
We have build jobs '''jgit.gerrit''' on https://hudson.eclipse.org/jgit/, and '''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.<br />
<br />
Sometimes you may want to retrigger such a build e.g. because it may have failed due to some temporary problem.<br />
Committers can manually trigger these jobs in the following way:<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
If you are not a committer and need to retrigger a build ask for that on the mailing list.<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Naming_Conventions&diff=299307Naming Conventions2012-04-24T11:21:04Z<p>Michael.keppler.gmx.de: /* Java Packages */ typo</p>
<hr />
<div>== General ==<br />
<br />
Like other open source projects, the code base for the Eclipse project should avoid using names that reference a particular company or their commercial products.<br />
<br />
=== Eclipse Workspace Projects ===<br />
<br />
When Eclipse is being used to develop plug-ins for the Eclipse project, the name of the Eclipse workspace project should match the name of the plug-in. For example, org.eclipse.core.runtime plug-in is developed in an Eclipse workspace project named org.eclipse.core.runtime.<br />
<br />
=== Java Packages ===<br />
<br />
The Eclipse Platform consists of a collection of Java packages. The package namespace is managed in conformance with Sun's package naming guidelines; subpackages should not be created without prior approval from the owner of the package subtree. The packages for the open-source Eclipse project are all subpackages of org.eclipse.<br />
<br />
The first package name segment after org.eclipse is generally the subproject name, followed by the component name.<br />
<br />
org.eclipse.<subproject>.<component>[.*]- General form of package names<br />
<br />
The following subprojects are assigned at the time of writing:<br />
<br />
org.eclipse.equinox.<component>[.*] - Equinox OSGi framework<br />
org.eclipse.jdt.<component>[.*] - Java development tooling<br />
org.eclipse.pde.<component>[.*] - Plug-in development environment<br />
<br />
The following package name segments are reserved:<br />
<br />
internal - indicates an internal implementation package that contains no API<br />
tests - indicates a non-API package that contains only test suites<br />
examples - indicates a non-API package that contains only examples<br />
<br />
These name are used as qualifiers and appear between the subproject and component name:<br />
<br />
org.eclipse.<subproject>.internal.<component>[.*] - internal package<br />
org.eclipse.<subproject>.tests.<component>[.*] - tests<br />
org.eclipse.<subproject>.examples.<component>[.*] - examples<br />
<br />
In the case of the Eclipse Platform proper, there is no subproject name, and the qualifiers appear immediately after the component name:<br />
<br />
org.eclipse.<component>[.*] - Eclipse Platform proper<br />
org.eclipse.<component>.internal[.*] - Eclipse Platform internal package<br />
org.eclipse.<component>.tests[.*] - Eclipse Platform tests<br />
org.eclipse.<component>.examples[.*] - Eclipse Platform examples<br />
<br />
The following components of the Eclipse Platform proper are assigned at the time of writing:<br />
<br />
org.eclipse.ant[.*] - Ant support<br />
org.eclipse.compare[.*] - Compare support<br />
org.eclipse.core[.*] - Platform core<br />
org.eclipse.debug[.*] - Debug<br />
org.eclipse.help[.*] - Help support<br />
org.eclipse.jdi[.*] - Eclipse implementation of Java Debug Interface (JDI)<br />
org.eclipse.jface[.*] - JFace<br />
org.eclipse.platform[.*] - Documentation<br />
org.eclipse.scripting[.*] - Scripting support<br />
org.eclipse.sdk[.*] - SDK configuration<br />
org.eclipse.search[.*] - Search support<br />
org.eclipse.swt[.*] - Standard Widget Toolkit<br />
org.eclipse.ui[.*] - Workbench<br />
org.eclipse.update[.*] - Plug-in live update<br />
org.eclipse.vcm[.*] - Version and Configuration Management<br />
org.eclipse.webdav[.*] - WebDAV support<br />
<br />
For example,<br />
<br />
org.eclipse.jdt.internal.core.compiler - Correct usage<br />
org.eclipse.jdt.core.internal.compiler - Incorrect. internal should immediately follow subproject name.<br />
org.eclipse.core.internal.resources - Correct usage<br />
org.eclipse.internal.core.resources - Incorrect. internal should never immediately follow org.eclipse.<br />
org.eclipse.core.resources.internal - Incorrect. internal should immediately follow Eclipse Platform component name.<br />
<br />
=== API Packages ===<br />
API packages are ones that contain classes and interfaces that must be made available to ISVs. The names of API packages need to make sense to the ISV. The number of different packages that the ISV needs to remember should be small, since a profusion of API packages can make it difficult for ISVs to know which packages they need to import. Within an API package, all public classes and interfaces are considered API. The names of API packages should not contain internal, tests, or examples to avoid confusion with the scheme for naming non-API packages. Consult [[Eclipse/API Central]] for more detailed information on choosing and naming API elements.<br />
<br />
=== Internal Implementation Packages ===<br />
All packages that are part of the platform implementation but contain no API that should be exposed to ISVs are considered internal implementation packages. All implementation packages should be flagged as internal, with the tag occurring just after the major package name. ISVs will be told that all packages marked internal are out of bounds. (A simple text search for ".internal." detects suspicious reference in source files; likewise, "/internal/" is suspicious in .class files).<br />
<br />
=== Test Suite Packages ===<br />
All packages containing test suites should be flagged as tests, with the tag occurring just after the major package name. Fully automated tests are the norm; so, for example, org.eclipse.core.tests.resources would contain automated tests for API in org.eclipse.core.resources. Interactive tests (ones requiring a hands-on tester) should be flagged with interactive as the last package name segment; so, for example, org.eclipse.core.tests.resources.interactive would contain the corresponding interactive tests.<br />
<br />
=== Examples Packages ===<br />
All packages containing examples that ship to ISVs should be flagged as examples, with the tag occurring just after the major package name. For example, org.eclipse.swt.examples would contain examples for how to use the SWT API.<br />
<br />
=== Additional rules ===<br />
<br />
* Package names should contain only lowercase ASCII alphanumerics, and avoid underscore _ or dollar sign $ characters.<br />
<br />
== Classes and Interfaces ==<br />
<br />
Sun's naming guidelines states<br />
<br />
: Class names should be nouns, in mixed case with the first letter of each internal word capitalized. Try to keep your class names simple and descriptive. Use whole words - avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).<br />
<br />
Examples:<br />
* class Raster;<br />
* class ImageSprite;<br />
<br />
Interface names should be capitalized like class names. <br />
<br />
For interface names, we follow the "I"-for-interface convention: all interface names are prefixed with an "I". For example, "IWorkspace" or "IIndex". This convention aids code readability by making interface names more readily recognizable.<br />
<br />
Additional rules:<br />
<br />
: The names of exception classes (subclasses of Exception) should follow the common practice of ending in "Exception".<br />
<br />
== Methods ==<br />
<br />
Sun's naming guidelines states<br />
: Methods should be verbs, in mixed case with the first letter lowercase, with the first letter of each internal word capitalized.<br />
<br />
<br />
Examples:<br />
* run();<br />
* runFast();<br />
* getBackground(); <br />
<br />
<br />
Additional rules:<br />
: The names of methods should follow common practice for naming getters (getX()), setters (setX()), and predicates (isX(), hasX()).<br />
<br />
== Variables ==<br />
<br />
Sun's naming guidelines states<br />
<br />
: Except for variables, all instance, class, and class constants are in mixed case with a lowercase first letter. Internal words start with capital letters. Variable names should not start with underscore _ or dollar sign $ characters, even though both are allowed.<br />
<br />
: Variable names should be short yet meaningful. The choice of a variable name should be mnemonic - that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.<br />
<br />
Examples:<br />
* int i;<br />
* char c;<br />
* float myWidth;<br />
<br />
== Constants ==<br />
<br />
Sun's naming guidelines states<br />
<br />
: The names of variables declared class constants and of ANSI constants should be all uppercase with words separated by underscores ("_").<br />
<br />
Examples:<br />
* static final int MIN_WIDTH = 4;<br />
* static final int MAX_WIDTH = 999;<br />
* static final int GET_THE_CPU = 1;<br />
<br />
== Plug-ins and Extension Points ==<br />
<br />
All plug-ins (and plug-in fragments), including the ones that are part of the Eclipse Platform, like the Resources and Workbench plug-ins, must have unique identifiers following the same style of naming convention as Java packages. For example, the workbench plug-in is named org.eclipse.ui.<br />
<br />
The names of a plug-in and the names of the Java packages declared within the code library of that plug-in commonly align. For example, the org.eclipse.ui plug-in declares much of its code in packages named org.eclipse.ui.* . While alignment is the recommended practice, it is not an absolute requirement. For instance, the org.eclipse.ui plug-in also declares code in packages named org.eclipse.jface.*. The org.eclipse.ant.core plug-in declares code in packages named org.eclipse.ant.core and org.apache.tools.ant.*.<br />
<br />
The plug-in namespace is managed hierarchically; do not create plug-in without prior approval from the owner of the enclosing namespace.<br />
<br />
Extension points that expect multiple extensions should have plural names. For example, "builders" rather than "builder".<br />
<br />
== System Files and Settings ==<br />
<br />
By convention, files or folders that start with a period ('.') are considered "system files" and should not be edited by users or, directly, by other components that do not "own" them. <br />
<br />
Of special note is the ".settings" folder in a workspace project. This folder holds various forms of preference or metadata specific to that workspace project. Files in this directory do not have to start with a period (they are assumed "system files" as they are in a "system folder") but they must follow the same naming conventions outlined elsewhere in this guide. That is, they must identify themselves with their Eclipse Project's namespace (e.g. org.eclipse.jdt, org.eclipse.jst, etc). and they should be as specific as possible to denote the package they come from, or the function they are serving. For example, <br />
<br />
org.eclipse.jdt.core.prefs<br />
org.eclipse.jst.common.project.facet.core.prefs<br />
org.eclipse.wst.common.project.facet.core.xml<br />
<br />
Two obvious exceptions to this convention are the .classpath and .project files, but ... that's just because they were the first, before the large community of Eclipse was grasped. Following these namespace guidelines will help avoid conflicts where two plugins or projects could accidently pick the same name for a metadata file.</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EGit/Contributor_Guide&diff=291947EGit/Contributor Guide2012-02-25T07:08:16Z<p>Michael.keppler.gmx.de: fix egit repo URL</p>
<hr />
<div>{{EGit}} <br />
<br />
= Communication =<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Channel<br />
!JGit<br />
!EGit <br />
|-<br />
|Developer Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-dev JGit developer mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-dev EGit developer mailing list]<br />
|-<br />
|Build Notices Mailing List<br />
|[https://dev.eclipse.org/mailman/listinfo/jgit-build JGit build notices mailing list]<br />
|[https://dev.eclipse.org/mailman/listinfo/egit-build EGit build notices mailing list]<br />
|-<br />
|Reporting Bugs<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File new JGit bug]<br />
|[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File new EGit bug]<br />
|-<br />
|User Forum<br />
|colspan=2|[http://www.eclipse.org/forums/index.php?t=thread&frm_id=48 EGit User Forum]<br />
|}<br />
<br />
<br/><br />
<br />
= Development IDE Configuration =<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
JGit is using ''PDE/API Tools Environment Descriptions'' (for details see the following [https://git.eclipse.org/r/#/c/4785/ change]) to facilitate detecting code which isn't working on Java 5. Install ''PDE/API Tools Environment Descriptions'' from the release train repository to enable that (available starting with Indigo).<br />
<br />
== Libraries from Orbit ==<br />
<br />
In order to install the libraries from Orbit choose from one of the following alternatives:<br />
<br />
=== Install from Orbit P2 Repository ===<br />
<br />
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:<br />
<br />
* Java Mocking and Stubbing Framework<br />
* Args4j<br />
* Protocol Buffers<br />
* Apache Jakarta log4j Plug-in<br />
* Hamcrest Library of Matchers<br />
<br />
=== Import Team Project Set ===<br />
The simplest way to import the 3rd party libraries needed to compile JGit and Egit:<br />
*Download the Team Project Set for [http://wiki.eclipse.org/images/9/9c/GitDependencies.psf git dependencies]<br />
*File > Import > Team > Team Project Set<br />
*Next <br />
*Select the downloaded GitDependencies.psf<br />
*logon with user "anonymous", leave password field blank<br />
*Finish<br />
<br />
=== Manual Import ===<br />
Alternatively to importing the team project set, you may do a manual import of the required libraries:<br />
<br />
''com.google.protobuf''<br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools''' <br />
*Use module '''org.eclipse.orbit/com.google.protobuf''' <br />
*Finish <br />
*Right click on the project &gt; Team &gt; Switch to another branch <br />
*Select tag from following list <br />
*Refresh Tags <br />
*Versions &gt; v201105131100 <br />
<br />
''org.mockito'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools''' <br />
*Use module '''org.eclipse.orbit/org.mockito''' <br />
*Finish <br />
*Right click on the project &gt; Team &gt; Switch to another branch <br />
*Select tag from following list <br />
*Refresh Tags <br />
*Versions &gt; v201102171835<br />
<br />
''org.objenesis'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org:/cvsroot/tools''' <br />
*Use module '''org.eclipse.orbit/org.objenesis''' <br />
*Finish <br />
*Right click on the project &gt; Team &gt; Switch to another branch <br />
*Select tag from following list <br />
*Refresh Tags <br />
*Versions &gt; v201006030720<br />
<br />
''org.kohsuke.args4j'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/tools''' <br />
*Use module '''org.eclipse.orbit/org.kohsuke.args4j''' <br />
*Finish <br />
*Right click on the project &gt; Team &gt; Switch to another branch <br />
*Select tag from following list <br />
*Refresh Tags <br />
*Branches &gt; v2_0_12<br />
<br />
''javax.servlet'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/tools''' <br />
*Use module '''org.eclipse.orbit/javax.servlet''' <br />
*Finish <br />
*Right click on the project &gt; Team &gt; Switch to another branch <br />
*Select tag from following list <br />
*Refresh Tags <br />
*Branches &gt; v2_5<br />
<br />
<br/><br />
<br />
= Obtaining Sources =<br />
<br />
EGit and JGit are self hosted in Git. Browse the repositories in cgit here<br />
[http://git.eclipse.org/c/egit/ EGit repositories] and [http://git.eclipse.org/c/jgit/ JGit].<br />
<p>There are several ways to obtain a copy of each repository:</p><br />
<br />
== From the command line ==<br />
<pre style="width: 40em;"><br />
git clone https://git.eclipse.org/r/p/egit/egit.git<br />
git clone https://git.eclipse.org/r/p/egit/egit-github.git<br />
git clone https://git.eclipse.org/r/p/egit/egit-pde.git<br />
</pre><br />
<br />
== From an [http://www.eclipse.org/egit/download/ installed] EGit plugin ==<br />
First, verify that the default repository folder as set on the main Git preference page is to your liking.<br />
<br />
*File &gt; Import &gt; Git > Projects from Git<br />
*Clone...<br />
*Enter URI: <code>git clone https://git.eclipse.org/r/p/egit/egit.git</code> <br />
*Import existing projects into the workspace from the newly created working directory <br />
<br />
<br />
To compile properly you will also need [[#Libraries from Orbit|libraries from Orbit]].<br />
<br />
== EGit PDE Tools ==<br />
<br />
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. <br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
*Clone...<br />
*Enter URI: <code>https://git.eclipse.org/r/p/egit/egit-pde.git</code> <br />
*Import projects<br />
<br />
== EGit GitHub Integration ==<br />
<br />
EGit also provides tools for integrating with GitHub and Mylyn tasks.<br />
<br />
*File &gt; Import &gt; Git &gt; Projects from Git<br />
*Enter URI: <code>https://git.eclipse.org/r/p/egit/egit-github.git</code> <br />
*Clone...<br />
*Import projects<br />
*Download dependencies:<br />
** automagically: open 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 cgit] and select 'Set as Target Platfrom'.<br />
** 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.<br />
<br />
<br/><br />
<br />
= Builds =<br />
<br />
EGit and JGit builds run on build.eclipse.org via Hudson using <br />
* [http://maven.apache.org/download.html at least Maven 3.0.0]<br />
<br />
Hudson<br />
* [https://hudson.eclipse.org/hudson/job/jgit JGit@hudson.eclipse.org]<br />
* [https://hudson.eclipse.org/hudson/job/egit EGit@hudson.eclipse.org]<br />
<br />
== JGit ==<br />
* JGit can be built using Maven 2 or 3.<br />
* JGit packaging projects (Eclipse feature and update site) are built using Maven 3 and Tycho.<br />
<br />
== EGit ==<br />
* EGit is built using Maven 3 and Tycho.<br />
<br />
== Mailing Lists ==<br />
<br />
If you're interested in following builds, please check out the following mailing lists:<br />
<br />
*[https://dev.eclipse.org/mailman/listinfo/jgit-build Subscribe to jgit-build@eclipse.org]<br />
*[https://dev.eclipse.org/mailman/listinfo/egit-build Subscribe to egit-build@eclipse.org]<br />
<br />
== Maven Build Sequence ==<br />
* 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.<br />
* The 3 builds must share the same local Maven repository otherwise dependencies between these builds cannot be resolved.<br />
* 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><br />
<br />
Complete build sequence for a clean build (assuming $M2_HOME/bin is on the path and local Maven repository at ~/.m2/repository):<br />
<pre style="width: 55em;">[~/src/jgit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ mvn -f org.eclipse.jgit.packaging/pom.xml clean install<br />
[INFO] Scanning for projects...<br />
...<br />
<br />
[~/src/jgit] $ cd ../egit<br />
<br />
[~/src/egit] $ mvn clean install<br />
[INFO] Scanning for projects...<br />
...<br />
</pre><br />
<br />
The EGit build uses the JGit p2 repository to resolve jgit dependencies. For local builds the build assumes<br />
that egit and jgit source trees are located under a common parent folder. If this is not the case the path<br />
to the jgit p2 repository has to be injected via system property:<br />
<br />
<pre style="width: 55em;">[~/src/egit] $ mvn clean install -Djgit-site=file:/path/to/<br />
org.eclipse.jgit.updatesite/target/site<br />
</pre><br />
<br />
The hudson build on build.eclipse.org uses:<br />
<pre style="width: 55em;">[~/src/egit] $ mvn clean install -Djgit-site=https://build.eclipse.org/hudson/job/<br />
jgit/lastSuccessfulBuild/artifact/org.eclipse.jgit.packaging/<br />
org.eclipse.jgit.updatesite/target/site/<br />
</pre><br />
<br />
If you wan to build EGit for the specific Galileo platform, consider using the <code>platform-galileo</code> maven profile:<br />
[~/src/egit] $ mvn -P platform-galileo clean install<br />
<br />
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).<br />
<br />
== FindBugs and PMD ==<br />
<br />
As part of the build, JGit and EGit run FindBugs and PMD to find issues.<br />
* [https://hudson.eclipse.org/hudson/job/jgit/findbugs JGit FindBugs Results]<br />
* [https://hudson.eclipse.org/hudson/job/jgit/dry JGit DRY (PMD) Results]<br />
* [https://hudson.eclipse.org/hudson/job/egit/findbugs EGit FindBugs Results]<br />
* [https://hudson.eclipse.org/hudson/job/egit/dry EGit DRY (PMD) Results]<br />
<br />
== Automated Signing and Publishing ==<br />
EGit and JGit builds are signed and published using the eclipse-maven-signing-plugin<br />
via build.eclipse.org to the folder<br />
<pre><br />
/home/data/httpd/download.eclipse.org/egit/updates-nightly<br />
</pre><br />
<br />
To enable this procedure the maven profile <code>build-server</code> must be<br />
enabled via the option <code>-P build-server</code> in the egit build job <br />
running at https://hudson.eclipse.org/hudson/job/egit/<br />
<br />
==== Publishing (old method, replaced by automated procedure) ====<br />
<br />
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:<br />
<br />
<pre><br />
/home/data/httpd/download.eclipse.org/egit/pubegit.sh<br />
/home/data/httpd/download.eclipse.org/egit/pubegit-pde.sh<br />
</pre><br />
<br />
The script essentially fetches the latest successful build from Hudson and publishes it every three hours via a cron job.<br />
<br />
==== Signing (old method, replaced by automated procedure) ====<br />
<br />
To sign the EGit build, you need to have ssh access to build.eclipse.org and the ability to run '''/usr/bin/sign'''<br />
<br />
At the moment, Chris Aniszczyk (caniszczyk) and Matthias Sohn (msohn) have signing privileges.<br />
<br />
The first step is to ensure you're in a place you can sign on build.eclipse.org<br />
<br />
cd /home/data/httpd/download-staging.priv/commonBuild<br />
<br />
Next you run the signing command (Usage: /usr/bin/sign <file> <mail|nomail> [outputDir]) on a zip of the EGit repo...<br />
<br />
sign egit-p2-repo.zip my@email.com /home/data/users/caniszczyk/egit-0.8<br />
<br />
After that, you can publish the zip that is generated with the signing information.<br />
<br />
== Contribution to Release Train ==<br />
<br />
The Indigo release train contribution for JGit and EGit is maintained in the CVS project <br />
extssh://dev.eclipse.org/cvsroot/callisto/org.eclipse.indigo.build<br />
in the file<br />
egit.b3aggrcon<br />
<br />
<br/><br />
<br />
= Documentation =<br />
<br />
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]].<br />
<br />
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'''<br />
'''$ mvn clean install''' <br />
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<br />
'''$ mvn clean install -Dupdate.egit.doc'''<br />
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.<br />
<br />
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.<br />
<br />
<br/><br />
<br />
= Tests =<br />
== JGit Unit Tests ==<br />
The JGit unit tests are executed during the maven build for the bundle ''org.eclipse.jgit.test''.<br />
To run them from the Eclipse workbench use the launch configurations which are part of the sources of the bundle ''org.eclipse.jgit.test''.<br />
<br />
== JGit HTTP Tests ==<br />
The JGit HTTP tests rely on the Jetty web container. To run these tests from Eclipse install the jetty feature.<br />
<br />
If you are using Helios you can get it from here:<br />
<br />
http://download.eclipse.org/releases/helios<br />
<br />
Otherwise install it from here:<br />
<br />
http://download.eclipse.org/jetty/7.1.6.v20100715/repository<br />
<br />
Feature: Jetty - Core: servlets and webapps<br />
<br />
For Indigo (you'll need SR1 for that) install "Jetty Target Components 7.5.1.201109140245" from http://download.eclipse.org/releases/indigo.<br />
'''Note:''' there is a problem with the following Jetty versions 7.3.1.v20110307, 7.4.2.v20110526 which cause the JGit http tests to hang.<br />
<br />
== EGit Core Tests ==<br />
The EGit Core tests are executed during the maven build for the bundle ''org.eclipse.egit.core.test''.<br />
<br />
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]].<br />
<br />
== EGit UI Tests ==<br />
The EGit UI tests are using SWTBot, to run them you need 'SWTBot for Eclipse Testing' feature.<br />
<br />
=== Manual ===<br />
Install the SWTBot matching your Eclipse version <br />
* Galileo http://download.eclipse.org/technology/swtbot/galileo/dev-build/update-site<br />
* Helios and Indigo http://download.eclipse.org/technology/swtbot/helios/dev-build/update-site<br />
<br />
You need to install at least "SWTBot for Eclipse Testing" and "SWTBot IDE Feature".<br />
<br />
Starting a UI test from Eclipse:<br />
* select the test class or test method<br />
* click '''Run As > SWTBot Test'''<br />
<br />
[[Image:Start-swtbot-test.png]]<br />
<br />
Do not touch the mouse or keyboard when the UI test is running since this may<br />
disturb the UI test by e.g. moving the current focus to another window.<br />
<br />
=== Automatic ===<br />
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:<br />
* 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.<br />
* 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.<br />
<br />
How to use it:<br />
* pull either first or both patches<br />
* open Target Platform Preferences page (Window - Preferences - Plug-in development - Target Platform)<br />
* activate 'SWTBot-based UI plug-in tests' target platform<br />
<br />
=== During Maven Build ===<br />
<br />
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].<br />
<br />
If you want to skip execution of UI tests during the maven build run<br />
<br />
mvn -P skip-ui-tests clean install<br />
<br />
== Auxilary testing tools ==<br />
<br />
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.<br />
<br />
== Manual alpha testing ==<br />
In order to manually test your new feature<br />
* click '''Run > Run Configurations...'''<br />
* create a new launch configuration of type "Eclipse Application"<br />
* click '''Run'''<br />
* for debugging start the same launch configuration from '''Debug > Debug Configurations...'''<br />
<br />
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]<br />
<br />
= Bugs =<br />
== Links ==<br />
=== Filing Bugs ===<br />
[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=EGit&rep_platform=All&op_sys=All File a bug for EGit]<br />
<br />
[https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JGit&rep_platform=All&op_sys=All File a bug for JGit]<br />
<br />
=== Bug Reports and Links ===<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Trends<br />
!EGit<br />
!JGit<br />
|-<br />
|Open Bugs and Enhancements<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED Open]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED Open]<br />
|-<br />
|Assigned Bugs and Enhancements<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=ASSIGNED Assigned]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=ASSIGNED Assigned]<br />
|-<br />
|All Bugs and Enhancements<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=EGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|[https://bugs.eclipse.org/bugs/reports.cgi?product=JGit&datasets=NEW&datasets=REOPENED&datasets=UNCONFIRMED&datasets=VERIFIED&datasets=CLOSED&datasets=RESOLVED All]<br />
|-<br />
!Lists<br />
!EGit<br />
!JGit<br />
|-<br />
| <span style="color:red">Unresolved for passed Target Milestones</span><br />
| [https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Technology&field0-0-0=everconfirmed&list_id=516352&product=EGit&query_format=advanced&target_milestone=0.6.0&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=1.0.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=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.10.0&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.11&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.12&target_milestone=0.9.0-M1&target_milestone=0.9.0-M2&target_milestone=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.10.0&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.11&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.12&target_milestone=1.1-M1&target_milestone=1.1-M2&target_milestone=1.1-M3&target_milestone=1.1&target_milestone=1.1-M1&target_milestone=1.1&target_milestone=1.2-M1&target_milestone=1.2-M2&target_milestone=1.2&target_milestone=1.3&order=target_milestone%2Cbug_status%2Cbug_id&query_based_on= Open]<br />
| [https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&classification=Technology&field0-0-0=everconfirmed&list_id=516352&product=JGit&query_format=advanced&target_milestone=0.6.0&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=1.0.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=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.10.0&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.11&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.12&target_milestone=0.9.0-M1&target_milestone=0.9.0-M2&target_milestone=0.10.0-M1&target_milestone=0.10.0-M2&target_milestone=0.10.0-M3&target_milestone=0.10.0&target_milestone=0.11-M1&target_milestone=0.11-M2&target_milestone=0.11&target_milestone=0.12-M1&target_milestone=0.12-M2&target_milestone=0.12&target_milestone=1.1-M1&target_milestone=1.1-M2&target_milestone=1.1-M3&target_milestone=1.1&target_milestone=1.1-M1&target_milestone=1.1&target_milestone=1.2-M1&target_milestone=1.2-M2&target_milestone=1.2&target_milestone=1.3&order=target_milestone%2Cbug_status%2Cbug_id&query_based_on= Open]<br />
|-<br />
| Open Bugs<br />
| [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]<br />
| [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]<br />
|-<br />
| Open Enhancements<br />
|[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]<br />
|[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]<br />
|-<br />
| Assigned Bugs and Enhancements<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=EGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?product=JGit&bug_status=ASSIGNED&order=bug_severity Assigned]<br />
|-<br />
! Reports<br />
! colspan=2 | EGit and JGit<br />
|-<br />
| Open EGit and JGit Bugs<br />
| 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]<br />
|-<br />
| Assigned EGit and JGit Bugs<br />
| 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]<br />
|-<br />
| New Bugs opened<br />
| [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]<br />
| [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]<br />
| [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=-1m&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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=-1y&chfieldto=Now&chfield=%5BBug+creation%5D&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|-<br />
| Bugs closed<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last day]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last week]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1m&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last month]<br />
| [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_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&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=-1y&chfieldto=Now&chfield=bug_status&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= Last year]<br />
|}<br />
<br />
<br/><br />
<br />
== Keywords ==<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
{| cellpadding="3" cellspacing="0" border="1"<br />
!Tag<br />
!Description<br />
!Link<br />
|-<br />
|[sync]<br />
|everything related to Synchronize / Synchronize View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Bsync%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[repoView]<br />
|everything related to the Git Repository View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BrepoView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[releng]<br />
|everything related to release engineering and build<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5Breleng%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|-<br />
|[historyView]<br />
|everything related to the Git History View<br />
|[https://bugs.eclipse.org/bugs/buglist.cgi?short_desc=%5BhistoryView%5D;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=ASSIGNED;bug_status=REOPENED;short_desc_type=allwordssubstr;product=EGit View bugs]<br />
|}<br />
<br />
<br/><br />
<br />
= Website =<br />
<br />
The EGit and JGit websites are located in a CVS repository on the Eclipse Foundation's servers.<br />
<br />
''egit'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse''' <br />
*Use module '''egit''' (from '''www''')<br />
*Finish<br />
<br />
''jgit'' <br />
<br />
*File &gt; Import &gt; CVS &gt; Projects from CVS <br />
*Select URL ''':pserver:anonymous@dev.eclipse.org/cvsroot/org.eclipse''' <br />
*Use module '''jgit''' (from '''www''')<br />
*Finish<br />
<br />
<br/><br />
<br />
= Contributing Patches =<br />
<br />
Review the following style guides: <br />
<br />
*[http://egit.eclipse.org/w/?p=jgit.git;a=blob;f=SUBMITTING_PATCHES;hb=HEAD JGit SUBMITTING_PATCHES] <br />
*[http://egit.eclipse.org/w/?p=egit.git;a=blob;f=SUBMITTING_PATCHES;hb=HEAD EGit SUBMITTING_PATCHES]<br />
<br />
== Using Gerrit at https://git.eclipse.org/r ==<br />
<br />
EGit and JGit projects are using [http://code.google.com/p/gerrit/ Gerrit Code Review] for Git based patch submission and review. <br />
<p>Parts of this chapter are also available in the [http://wiki.eclipse.org/Gerrit#Doing_Code_Reviews_with_Gerrit Eclipse Gerrit wiki].</p><br />
<br />
=== User Account ===<br />
*In order to contribute you need an [https://dev.eclipse.org/site_login/createaccount.php Eclipse user account], if you are an Eclipse committer you already have one<br />
* [https://git.eclipse.org/r/#settings,new-agreement Confirm you agree] to the Eclipse.org Terms of Service by completing the Individual Contributor agreement. <br />
<br />
=== Logon ===<br />
<br />
====Gerrit Web UI==== <br />
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.<br />
<br />
====Git over SSH==== <br />
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]. <br />
<br />
Gerrit SSH URl: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code><br />
<br />
====Git over HTTPS==== <br />
When accessing Gerrit over HTTPS from git or EGit use username and HTTP password displayed [https://git.eclipse.org/r/#/settings/http-password here]<br />
<br />
Gerrit HTTPS URl: <code>https://git.eclipse.org/r/p/egit/egit.git</code><br />
<br />
=== SSH Keys ===<br />
* Add one or more public SSH keys to [https://git.eclipse.org/r/#/settings/ssh-keys Gerrit here]. <br />
* 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.]<br />
* '''Generating SSH key pair on command line'''<br />
<pre style="width: 60em;">ssh-keygen -t rsa -C "your_email@youremail.com"</pre><br />
*Execute SSH once to accept the host key (or copy it from the registration web page)<br />
<pre style="width: 60em;">ssh -p 29418 username@git.eclipse.org<br />
</pre> <br />
* [http://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration Generating SSH key pair in Eclipse]<br />
<br />
=== Doing Code Reviews with Gerrit ===<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review instance] to start reviewing, <br />
*[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<br />
*Adjust your [https://git.eclipse.org/r/#/settings/preferences Gerrit preferences] to customize it to your needs<br />
*See the [https://git.eclipse.org/r/Documentation/index.html#_user_guide Gerrit user guide] for more information about using Gerrit.<br />
*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.<br />
*Use [https://git.eclipse.org/r/Documentation/user-search.html Gerrit queries] to filter the review list for changes you are interested in:<br />
**[https://git.eclipse.org/r/#/q/status:open+project:egit,n,z EGit changes pending in review]<br />
**[https://git.eclipse.org/r/#/q/status:open+project:jgit,n,z JGit changes pending in review]<br />
<br />
=== Using Gerrit with git command line: ===<br />
*Upload your patch from Git to the target project:<br />
<br />
'''JGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
'''EGit'''<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
==== Adding a dedicated remote ====<br />
<br />
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: <br />
<pre>cd path/to/jgit<br />
git config remote.review.url ssh://username@git.eclipse.org:29418/jgit/jgit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
<br />
cd path/to/egit <br />
git config remote.review.url ssh://username@git.eclipse.org:29418/egit/egit.git<br />
git config remote.review.push HEAD:refs/for/master<br />
</pre> <br />
You can now submit review requests from either repository using: <br />
<pre>git push review<br />
</pre><br />
<br />
=== Using Gerrit with EGit: ===<br />
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.<br />
* [[EGit/User_Guide#Cloning_Remote_Repositories | Clone the JGit and EGit repositories]] and use the last page of the Clone Wizard to [http://wiki.eclipse.org/EGit/User_Guide#Gerrit_Configuration configure pushing to the code review queue].<br />
* Alternative approach adding a review remote in the Git Repositories view:<br />
** From the appropriate Remotes node, create a New Remote and choose to Configure for Push. A unique name should be chosen, ''review'' is suggested.<br />
** Change the main URI or Add a Push URI (your Gerrit user name must be used here) <br />
*** JGit: <code>ssh://username@git.eclipse.org:29418/jgit/jgit.git</code><br />
*** EGit: <code>ssh://username@git.eclipse.org:29418/egit/egit.git</code> <br />
** In the Ref mapping section, add a RefSpec specification of <code>HEAD:refs/for/master</code><br />
** 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.<br />
<br />
*Visit the [https://git.eclipse.org/r/ Eclipse Gerrit Code Review server] to start reviewing<br />
<br />
== Granularity of Changes ==<br />
* Make small commits, as small as reasonable. This makes them easy to review.<br />
* 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.<br />
* 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.<br />
* Do not break the build and tests for '''any commit''': this is very important for bug hunting.<br />
* Split your work into multiple smaller pieces of work (when possible) and implement each of these pieces in a series of commits.<br />
* 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.<br />
* In a series of commits first lay the groundwork and then build on that towards the feature.<br />
* 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.<br />
<br />
== Coding standards == <br />
<br />
Eclipse has standards for how to write code.<br />
<br />
[[Coding_Conventions|Coding conventions]]<br />
<br />
[[User_Interface_Guidelines|Use interface guidelines]]<br />
<br />
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<br />
not sure about how to write a piece of code or design the user interface, these are the two<br />
first places to look at.<br />
<br />
In addition there is all the worlds collective knowledge on how to write programs that shine.<br />
When there is a conflict, the Eclipse guide lines and conventions take precedense.<br />
<br />
Breaking the rules is ok if there is a very good reason and you can tell us what that reason<br />
is.<br />
<br />
In addition to these general rules, we regard performance high. If the EGit plugin is slow <br />
in any way, that is a bug and should be reported and fixed. Java isn't slow, but there is a<br />
lot of slow Java code.<br />
<br />
== Commit message guidelines ==<br />
<br />
*The commit message header should fit on one line and should start with an uppercase letter<br />
*The commit message have newline characters after every 60-70 characters. <br />
*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"]<br />
*If a Gerrit Change-Id is available (for example when re-submitting to the same change), it should be added in the format below<br />
*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. <br />
*A "Signed-off-by" should be added to the end of the commit message (see example below).<br />
*The first sentence should be a clear and concise description about the change. <br />
*Enter a newline before providing a more detailed description about the change.<br />
<pre>Fix the commit dialog to respect the workbench's selection<br />
<br />
Originally, the commit dialog would automatically check off all<br />
files in the dialog. This behaviour contradicts a user's expectation<br />
because their selection in the workbench is completely ignored. The<br />
code has been corrected to only preselect what the user has actually<br />
selected.<br />
<br />
Bug: 12345<br />
Change-Id: I71ac4844ab9d2f848352eba9252090c586b4146a<br />
Signed-off-by: Your Name <your.email@example.org><br />
</pre><br />
<br />
== Test before submitting ==<br />
<br />
See the [[#Manual alpha testing]] section for some advice about how to test you work yourself.<br />
<br />
* Run all existing tests. It does not take very long.<br />
* 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.<br />
<br />
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).<br />
<br />
== Sending patches by mail ==<br />
<br />
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 [http://www.kernel.org/pub//software/scm/git/docs/git-send-email.html git send-email]. Instead, please use [http://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html git format-patch] to generate the <code>mbox</code>, and then attach that to an item in bugzilla as per the above SUBMITTING_PATCHES guides. <br />
<br />
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. <br />
<br />
'''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.<br />
<br />
<br/><br />
<br />
= Gerrit Code Review Cheatsheet =<br />
<br />
== Install the commit-msg hook in your repository ==<br />
<pre style="width: 60em;">scp -p -P 29418 username@git.eclipse.org:hooks/commit-msg .git/hooks/<br />
</pre> <br />
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.<br />
<br />
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.<br />
<br />
== To create a new change ==<br />
<br />
*JGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/jgit/jgit.git HEAD:refs/for/master<br />
</pre> <br />
*EGit<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
Or, if you've followed the instructions on [[#Adding_a_remote]] you can simply do: <br />
<pre style="width: 60em;">git push review<br />
</pre> <br />
Since the current repository has the right definition for 'review', you won't need to remember the canonical push URL<br />
<br />
== To update an existing change with a new commit ==<br />
<pre style="width: 60em;">git push ssh://username@git.eclipse.org:29418/egit/egit.git HEAD:refs/for/master<br />
</pre> <br />
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].<br />
<br />
'''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 :).<br />
<br />
== To compare bulk diffs using Git ==<br />
<br />
Since each Gerrit review patchset actually commits its own tree, you can pull out the trees and compare them. <br />
<br />
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: <br />
<br />
*Patch Set 1 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/1 (1d3331a91bd477d3f70cde9613576cf9688ac358)</code> <br />
*Patch Set 2 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/2 (13ab9a43d4d512963556a92e889b1204d32f8e68)</code> <br />
*Patch Set 3 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/3 (d14cc645655683ba3e30a35833fb2282142e898f)</code> <br />
*Patch Set 4 <code>git pull ssh://username@git.eclipse.org/jgit refs/changes/02/2/4 (43de8d385b614c72fd796e17da75d381f6e0cc25)</code><br />
<br />
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: <br />
<pre>git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/3<br />
git fetch ssh://username@git.eclipse.org/jgit refs/changes/02/2/4<br />
<br />
git diff d14cc645655683ba3e30a35833fb2282142e898f 43de8d385b614c72fd796e17da75d381f6e0cc25<br />
<br />
# or git diff d14cc6 43de8d<br />
</pre> <br />
If you're doing this from within an already checked out project, you can do <code>git fetch origin</code> (or any other remote name in <code>.git/config}</code>. <br />
<br />
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 <code>git gc</code> or wait until this happens automatically.<br />
<br />
== To trigger Hudson build for a change ==<br />
<br />
*Go to [https://hudson.eclipse.org/sandbox/gerrit_manual_trigger/ Trigger a Gerrit event manually] page <br />
*Search for a change you'd like to build<br />
*Select the patch set(s) you want to trigger<br />
*Press '''Trigger Selected''' button<br />
<br />
== To approve a change ==<br />
<br />
*Click on Publish Comments <br />
*Vote with the radio buttons<br />
<br />
== To add a reviewer ==<br />
<br />
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.<br />
<br />
== Code Review ==<br />
<br />
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. <br />
<br />
== IP Review ==<br />
<br />
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.<br />
<br />
== Submission Guidelines ==<br />
<br />
We strive to use Gerrit to improve our understanding of the code base and improve quality. <br />
<br />
In order to ensure a proper review happens, some simple guidelines should be followed:<br />
<br />
* vote 0/-1 for not-ready-to-submit (AKA WIP) own proposals, +1 otherwise;<br />
* If a changeset is not-ready-to-submit, please put [RFC] or [DRAFT] in the message to let people know<br />
* let non-trivial changes be in review for at least 24 hours<br />
* if you want your changeset reviewed by someone, please add them as a reviewer<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Class Loading Issues ===<br />
<br />
If you encounter strange class loading issues during runtime (e.g. on UI test executions) the following might help:<br />
<br />
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.<br />
<br />
[[Category:Draft_Documentation]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Category:Auto_IWG&diff=274532Category:Auto IWG2011-10-26T12:38:35Z<p>Michael.keppler.gmx.de: categorize</p>
<hr />
<div>All pages in this category are related to the [[Automotive Industry Working Group]].</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG_WP5&diff=274531Auto IWG WP52011-10-26T12:37:33Z<p>Michael.keppler.gmx.de: categorize, link back</p>
<hr />
<div>==== WP5: Eclipse Qualification Kit (ISO26262)====<br />
This is work package 5 of the [[Automotive Industry Working Group]].<br />
<br />
* WP Lead: Bredex (temporary)<br />
<br />
Need to share knowledge and resources in the classification/qualification activities of eclipse related products. It has been decided that this activities require a dedicated WP.<br />
Interested parties: all<br />
TODO (Bredex): Definition/description of WP.<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG_WP4&diff=274530Auto IWG WP42011-10-26T12:37:02Z<p>Michael.keppler.gmx.de: categorize, link back</p>
<hr />
<div>=== WP4: Functional Safety Relevant Development Process and Environment ===<br />
This is work package 4 of the [[Automotive Industry Working Group]].<br />
<br />
* WP Lead: ITEMIS (A. Graf)<br />
<br />
Functional Safety has an impact on Eclipse based tooling in two dimensions: First, which tools can be used to develop safety-relevant functions. Secondly, what are the implications of standards like ISO26262 on the development of Eclipse-based tooling?<br />
<br />
This work package has one initial task: Every company rep to discuss internally who the right<br />
people within the organizations are to connect to<br />
* Identify the stakeholders in the IWG member companies, then (unless otherwise decided)<br />
* Definition of scope<br />
* Clarification of requirements<br />
* Define approach<br />
* Connect to OPEES, OpenETCS<br />
* SAFE project: [http://www.safe-project.eu/]<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG_WP3&diff=274529Auto IWG WP32011-10-26T12:36:23Z<p>Michael.keppler.gmx.de: categorize, link back</p>
<hr />
<div>=== WP3: CDT Extensions ===<br />
This is work package 3 of the [[Automotive Industry Working Group]].<br />
<br />
*WP Lead: Continental (I. Garro)<br />
<br />
The development of embedded systems in the automotive area has additional requirements to CDT that will be collected, analyzed and<br />
supported from this working group. Features that will eventually be covered here are:<br />
* Binary Parsing, Memory parsing<br />
* Make extensions, generic compiler support<br />
* Better support for C<br />
* Static Analysis<br />
* Profiler Support<br />
* C-Unit Support<br />
<br />
<br />
<br />
== Wishlist ==<br />
<br />
In addition to the list of frequently used components, the working group also identified a list of topics that should be addressed in future distributions:<br />
<br />
* Broad support of MISRA-C in the components<br />
* Target Device emulation / Simulation<br />
* Strategy for a model repository / distributed collaboration aspects<br />
* Support for Component testing and Code Coverage Analysis<br />
* Full Debugger Support<br />
* Build management support<br />
* C preprosessor enhancement<br />
* Product line support / Variant management. <br />
* C metamodel that includes preprocessor statements.<br />
* C++ (ANSI-C++ and/or embedded specific dialects like Extended Embedded C++ )<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG_WP2&diff=274528Auto IWG WP22011-10-26T12:34:48Z<p>Michael.keppler.gmx.de: categorize, link back</p>
<hr />
<div>=== WP2: Huge Models Support ===<br />
This is work package 2 of the [[Automotive Industry Working Group]].<br />
<br />
* WP Lead: ITEMIS (S. Eberle)<br />
<br />
Large models that exist in the automotive engineering space tend to create performance, loading, saving<br />
and other problems with the existing Eclipse implementations. The work package intents to find<br />
resolutions for these issues.<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Automotive_Industry_Working_Group&diff=274526Automotive Industry Working Group2011-10-26T12:32:48Z<p>Michael.keppler.gmx.de: Redirecting to Auto IWG</p>
<hr />
<div>#REDIRECT [[Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG_WP1&diff=274525Auto IWG WP12011-10-26T12:31:58Z<p>Michael.keppler.gmx.de: categorize, link back</p>
<hr />
<div>=== WP1: Technology Recommendations : Eclipse Automotive Tools Platform ===<br />
This is work package 1 of the [[Automotive Industry Working Group]].<br />
<br />
*Project Lead: Bosch (TBD)<br />
<br />
A dedicated Eclipse distribution for Automotive Tool Developers could be a first concrete step and deliverable of this IWG. The idea is to identify a set of existing Eclipse projects and components that are typically required and used in automotive tool development and make them available as a new Eclipse distribution at Eclipse.org. Though not including any automotive specific content yet, we believe that such an Eclipse distribution makes anyway sense because of the following reasons:<br />
<br />
* It points out which Eclipse projects and components are actively used in the automotive industry<br />
* It gives an orientation regarding the Eclipse release which automotive tool development is typically based on<br />
* It eases the provision and maintenance of the Eclipse platform required for automotive tool development <br />
<br />
It is important to note that such an Eclipse distribution is addressed to automotive tool developers but not to automotive tool users. In other words, it is not meant as something that ECU software developers could use out of the box and find useful. It is intended as starting point and target platform which ECU software tool developers can base their work on. What ECU software developers will eventually be provided with, are mostly the tools resulting for the ECU software tool development plus the dependent parts of the Eclipse Tool Developer distribution.<br />
<br />
[[Proposed Components]]<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Auto_IWG&diff=274524Auto IWG2011-10-26T12:29:27Z<p>Michael.keppler.gmx.de: categorize Auto IWG pages</p>
<hr />
<div>'''Open Source Initiative for Automotive Software Development Tools'''<br />
<br />
== Objectives ==<br />
<br />
Innovation in the automotive industry is mostly achieved by electronics and software functions. The system automobile is becoming increasingly complex, an open developer tool workbench that extends throughout the supply-chain is becoming a must for the industry. Improvements and innovations to these software development tools are required to accelerate product development, create high quality software features and improve integration across the automotive supply chain.<br />
<br />
The Eclipse Foundation is pleased to announce the creation of a new open source initiative to define and implement a standard platform for the software development tools used in the automotive industry. The new Eclipse Automotive Industry Working Group will be open to any organizations that want to participate in the goal of establishing a standard tools platform that will be used throughout the automotive supply chain.<br />
<br />
* To provide an infrastructure for tool development required by the automotive industry<br />
* To address and support the needs for the whole automotive software development cycle<br />
* To avoid that the same non-competitive basic tool functionality is redeveloped over and over again<br />
* To join forces and meet current and future requirements in terms of tool runtime performance and memory consumption<br />
<br />
The charter of group can be found [http://www.eclipse.org/org/industry-workgroups/autowg.php here]<br />
<br />
== Organization and Contact ==<br />
{|<br />
|Spokesperson: ||'''Andreas Graf''', itemis AG<br />
|-<br />
|Steering Committee Chair:|| '''Ignacio Garro''', Continental AG<br />
|-<br />
|Steering Committee: ||see [http://dev.eclipse.org/mhonarc/lists/auto-iwg/msg00069.html] <br />
|-<br />
|}<br />
For more information, contact ralph (dot) mueller (at) eclipse (dot) org<br />
<br />
See also the [https://dev.eclipse.org/mailman/listinfo/auto-iwg Auto IWG Mailing List] <br \><br />
<br />
== News, Meetings and Activities ==<br />
<br />
'''The next meeting is February 16th in Stuttgart!'''<br />
<br />
Press Release 20. 07. 2011: [http://www.eclipse.org/org/press-release/20110720_autoiwg.php New Open Source Initiative for Automotive Software Development Tools]<br />
<br />
A list of past meetings and meeting minutes is at [[Auto IWG Meetings]]<br />
<br />
== Work Packages ==<br />
<br />
=== WP1: Technology Recommendations : Eclipse Automotive Tools Platform ===<br />
Definition of a common Automotive Eclipse Tool Platform. More information here: [[Auto_IWG_WP1]]<br />
<br />
=== WP2: Huge Models Support ===<br />
Large models that exist in the automotive engineering space tend to create performance, loading, saving<br />
and other problems with the existing Eclipse implementations. The work package intents to find<br />
resolutions for these issues.<br />
<br />
More information here: [[Auto_IWG_WP2]]<br />
<br />
=== WP3: CDT Extensions ===<br />
The development of embedded systems in the automotive area has additional requirements to CDT that will be collected, analyzed and<br />
supported from this working group. <br />
<br />
More information here: [[Auto_IWG_WP3]]<br />
<br />
=== WP4: Functional Safety Relevant Development Process and Environment ===<br />
Focus of this WP shall be to analyze which functions should have a toolchain in a safety environment. <br />
<br />
More information here: [[Auto_IWG_WP4]]<br />
<br />
=== WP5: Eclipse Qualification Kit (ISO26262) ===<br />
Definition of qualification support elements for the functional safety qualification of eclipse based tools.<br />
<br />
More information here: [[Auto_IWG_WP5]]<br />
<br />
== Related Eclipse Projects ==<br />
<br />
incomplete: <br />
* [http://www.eclipse.org/cdt/ CDT]<br />
* [http://www.eclipse.org/modeling/mdt/papyrus/ Papyrus]<br />
* [http://www.eclipse.org/sphinx/ Sphinx]<br />
<br />
New proposal: <br />
<br />
[http://www.eclipse.org/proposals/modeling.mdt.rmf/ Requirements Modeling Framework]<br />
<br />
== External Links ==<br />
<br />
[http://artop.org AUTOSAR Tool Platform (Artop)] <br \><br />
[http://www.edona.fr/scripts/home/publigen/content/templates/show.asp?L=EN&P=55&vTicker=alleza Edona Project] <br \><br />
[http://topcased.org/ Topcased Project] <br \><br />
[http://www.safe-project.eu/ SAFE project]<br />
<br />
[[Category:Auto IWG]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EclipseCon_Europe_Exercise_2011&diff=272951EclipseCon Europe Exercise 20112011-10-17T10:03:04Z<p>Michael.keppler.gmx.de: /* Route */</p>
<hr />
<div>Part of [http://eclipsecon.org EclipseCon Europe 2011]<br />
<br />
Sign up today! Just fill in your name, the days you'll be participating, and your email address below.<br><br />
<br />
== ''Don't miss out on all the fun &ndash; sign up now for the daily run!'' ==<br />
<br />
== Time and Place ==<br />
* Wednesday, November 2 through Friday, November 4<br />
* Meet in the lobby of the Nestor Hotel at 7am<br />
<br />
== A Few Benefits ==<br />
<br />
* Feel energized<br />
* Get a great start to a full day<br />
* Meet members of the community, and get to know them better <br />
* Help your mind get ready to focus on the outstanding talks EclipseCon Europe has to offer<br />
* Burn off some calories<br />
* Breathe in the crisp, clean autumn air<br />
<br />
== Route ==<br />
Through Ludwigsburg's beautiful Favoritepark;<br />
<br />
details [http://www.dailymile.com/routes/48171-running-route-in-ludwigsburg-de here] or even more detailed [http://openrouteservice.org/index.php?start=9.1944839,48.8911803&end=9.1947521,48.8910722&via=9.1887950,48.9086500%20&pref=Pedestrian&lang=en&noMotorways=false&noTollways=false&zoom=14&lat=48.89987&lon=9.19256&layers=TB000FFFTTTTTTF here]<br />
<br />
One possible problem with the listed route - the other years the park has been closed access in the morning... /Tonny<br />
<br />
The Favoritepark is only open from 9 to 18 o'clock, so the last part of the shown routes will not be possible.<br />
<br />
== Participants ==<br />
<br />
Add your name here! Include your email address, and the days you'll be running or walking. <br />
<br />
#Kim Moir, Wednesday, Thursday, Friday [mailto:kmoir@ca.ibm.com]<br />
#Tonny Madsen, all three days [mailto:tonny.madsen@gmail.com]<br />
#Hendrik Eeckhaut, Thursday [mailto:hendrik.eeckhaut@sigasi.com]<br />
#<br />
#</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Graphical_Modeling_Framework/Tutorial/Part_3&diff=263533Graphical Modeling Framework/Tutorial/Part 32011-08-03T13:12:42Z<p>Michael.keppler.gmx.de: /* Advanced customization */ typo</p>
<hr />
<div>= Advanced customization =<br />
<br />
This third part is dedicated to customization that you cannot make using the generation models. This is where you'll have to code to customize your process. But don't worry, GMF Runtime provides a lot of stuff to make it easier. The complete solution to this tutorial is maintained in CVS [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmp/org.eclipse.gmf.tooling/examples/?root=Modeling_Project here]. Viewlets will be available after appropriate sections below to focus their content and keep them short.<br />
<br />
== Creating a Customization Plug-in ==<br />
Although making modifications to the generated code and specifying '@generated NOT' to allow JMerge to preserve our changes works well for some customizations, it's also possible to separate other customizations (extensions) to our generated plug-in using a new plug-in. For this purpose, create a new plug-in project named org.eclipse.gmf.examples.mindmap.diagram.custom to your workspace. Use the default settings, although no Activator class is needed, nor is the use of any of the templates provided in the wizard.<br />
<br />
=== Custom Actions ===<br />
[[Image:insert_subtopic.png|frame|right]]<br />
The standard means to create a new subtopic is a bit painful at the moment: click on Topic creation tool, then diagram, name with in-place editor, click Subtopic link creation tool, draw link from parent to subtopic. Ideally, we'd like to simply use a right-click menu option on a selected Topic and choose "Create Subtopic" or better yet, press the Insert key (or some combination) and have the new Topic created, including the link, and with the in-place editor active on the new Topic. In this section, we will explore how to accomplish just this.<br />
<br />
To begin, we know that the org.eclipse.ui.bindings can be used to assign a Ctrl+I key combination to our action (as seen on the image, though for OS X). This is easily accomplished by contributing to the extension-point in our new *.diagram.custom plugin.xml file. Note that this is a simplistic example that does not declare a context, as you would probably expect to create for your diagram and potentially extend a default GMF diagram context (if one existed ;-).<br />
<br />
<source lang="xml"><br />
<extension point="org.eclipse.ui.bindings"><br />
<key commandId="org.eclipse.gmf.examples.mindmap.insertSubtopic" sequence="M1+I" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration"/><br />
</extension><br />
</source><br />
<br />
Now, for the command, we'll contribute to the org.eclipse.ui.commands extension-point, as seen below. When you run your diagram, you will see this command category and the shortcut listed in the General | Keys preference page.<br />
<br />
<source lang="xml"><br />
<extension point="org.eclipse.ui.commands"><br />
<category name="Mindmap" description="Commands related to Mindmap diagrams." id="org.eclipse.gmf.category.mindmap"/><br />
<command categoryId="org.eclipse.gmf.category.mindmap" description="Inserts a new subtopic" id="org.eclipse.gmf.examples.mindmap.insertSubtopic" name="Insert Subtopic"><br />
</command><br />
</extension><br />
</source><br />
<br />
Now, for the popup menu. We'd like to have a series of potential menu items to insert elements on our diagram (i.e. subtopics, threads, etc.), so our contribution to org.eclipse.ui.popupMenus will define an 'Insert | Subtopic' menu and link it to our binding above through the defintionId:<br />
<br />
<source lang="xml"><br />
<extension point="org.eclipse.ui.popupMenus"><br />
<objectContribution<br />
adaptable="false"<br />
id="org.eclipse.gmf.examples.mindmap.diagram.ui.objectContribution.TopicEditPart1"<br />
objectClass="org.eclipse.gmf.examples.mindmap.diagram.edit.parts.TopicEditPart"><br />
<menu <br />
id="MindmapInsert" <br />
label="&amp;Insert" <br />
path="additions"> <br />
<separator name="group1"/><br />
</menu><br />
<action<br />
class="org.eclipse.gmf.examples.mindmap.diagram.part.MindmapCreateSubtopicAction"<br />
definitionId="org.eclipse.gmf.examples.mindmap.insertSubtopic"<br />
enablesFor="1"<br />
id="org.eclipse.gmf.examples.mindmap.popup.MindmapCreateSubtopicActionID"<br />
label="&amp;Subtopic"<br />
menubarPath="MindmapInsert/group1"><br />
</action><br />
</objectContribution> <br />
</extension><br />
</source><br />
<br />
Now, for the fun part... to define the declared MindmapCreateSubtopicAction class. To begin, we know that similar functionality exists in the connection handles feature provided by the runtime (see image below).<br />
[[Image:connection_handle.png|frame|left]]<br />
<br style="clear:both;"/><br />
<br />
After some investigation, it seems the CreateViewAndOptionallyElementCommand class gives us a hint at how to implement what we want (thanks to Cherie for providing a simplied version of the original tutorial code below, which leverages the DeferredCreateConnectionViewAndElementCommand). <br />
<source lang="java"><br />
public void run(IAction action) {<br />
CompoundCommand cc = new CompoundCommand("Create Subtopic and Link");<br />
<br />
// Create the new topic for the other end.<br />
CreateViewRequest topicRequest = CreateViewRequestFactory.getCreateShapeRequest(MindmapElementTypes.Topic_2001, selectedElement.getDiagramPreferencesHint());<br />
<br />
Point p = selectedElement.getFigure().getBounds().getTopRight().getCopy();<br />
selectedElement.getFigure().translateToAbsolute(p);<br />
int edgeCount = selectedElement.getNotationView().getSourceEdges().size();<br />
// A quick hack to get subtopics to layout to the right, from top to bottom<br />
int offset = (edgeCount * 50) - 100;<br />
topicRequest.setLocation(p.translate(100, offset));<br />
<br />
MapEditPart mapEditPart = (MapEditPart) selectedElement.getParent();<br />
Command createTopicCmd = mapEditPart.getCommand(topicRequest);<br />
IAdaptable topicViewAdapter = (IAdaptable) ((List) topicRequest.getNewObject()).get(0);<br />
<br />
cc.add(createTopicCmd);<br />
<br />
// create the subtopics link command<br />
ICommand createSubTopicsCmd = new DeferredCreateConnectionViewAndElementCommand(new CreateConnectionViewAndElementRequest(MindmapElementTypes.TopicSubtopics_4001,<br />
((IHintedType) MindmapElementTypes.TopicSubtopics_4001).getSemanticHint(), selectedElement.getDiagramPreferencesHint()), new EObjectAdapter((EObject) selectedElement.getModel()),<br />
topicViewAdapter, selectedElement.getViewer());<br />
<br />
cc.add(new ICommandProxy(createSubTopicsCmd));<br />
<br />
selectedElement.getDiagramEditDomain().getDiagramCommandStack().execute(cc);<br />
<br />
// put the new topic in edit mode<br />
final EditPartViewer viewer = selectedElement.getViewer();<br />
final EditPart elementPart = (EditPart) viewer.getEditPartRegistry().get(topicViewAdapter.getAdapter(View.class));<br />
if (elementPart != null) {<br />
Display.getCurrent().asyncExec(new Runnable() {<br />
<br />
public void run() {<br />
viewer.setSelection(new StructuredSelection(elementPart));<br />
Request der = new Request(RequestConstants.REQ_DIRECT_EDIT);<br />
elementPart.performRequest(der);<br />
}<br />
});<br />
}<br />
}<br />
</source><br />
Rather than type in the code, simply copy the MindmapCreateSubtopicAction class into your project from the solution in CVS. If you observe any Access Restriction errors, add the required packages to the Exported Packages list on the Runtime of the *.diagram plugin. The basic concepts are outlined next.<br />
<br />
Our action will implement IObjectActionDelegate, with its run method performing the following:<br />
* create and initialize a CreateConnectionRequest<br />
* create and execute a CompoundCommand, containing a DeferredCreateConnectionViewAndElementCommand<br />
* create and perform a direct edit request on the new subtopic<br />
[[Image:inserted_subtopic.png|frame|right]]<br />
Run the diagram and test the functionality using the keyboard combination (Ctrl+I) or right-click menu. Note that the subtopic is created above and to the right of the parent with direct editing enabled for you to give it a name. As you can see, the code to determine the position is a temporary hack (layout will be covered in another installment of the tutorial).<br />
<br style="clear:both;"/><br />
<br />
=== Custom Layout ===<br />
Clearly, the default layout provided is not appropriate for a mindmap. What we are about to add is also less than optimal, but will indicate what is necessary to add a custom layout to your diagram. As described in the [http://help.eclipse.org/help33/topic/org.eclipse.gmf.doc/examples-guide/diagram/layoutServiceExample.html Layout Service Example], we will contribute an extension to the runtime's layoutProviders extension-point.<br />
<br />
We'll try two layouts: one that extends org.eclipse.gmf.runtime.diagram.ui.providers.LeftRightProvider; the other, extending org.eclipse.gmf.runtime.diagram.ui.providers.internal.RadialProvider ''(To access these class you need to include org.eclipse.gmf.runtime.diagram.ui.providers in your project dependancies)''. For each, add the appropriate extension in your plugin.xml file, setting the Priority higher for the one you'd like to take precedence. For example:<br />
<source lang="xml"><br />
<extension point="org.eclipse.gmf.runtime.diagram.ui.layoutProviders"><br />
<layoutProvider class="org.eclipse.gmf.examples.mindmap.diagram.layout.MindmapDefaultLayoutProvider"><br />
<Priority name="Medium"/><br />
</layoutProvider><br />
</extension><br />
</source><br />
<br />
The code for the LeftRightProvider is below:<br />
<source lang="java"><br />
public class MindmapDefaultLayoutProvider<br />
extends LeftRightProvider {<br />
<br />
public static String DEFAULT_LAYOUT = "Default";<br />
<br />
public boolean provides(IOperation operation) {<br />
// enable this provider only on mindmap diagrams<br />
if (operation instanceof ILayoutNodeOperation) {<br />
Iterator nodes = ((ILayoutNodeOperation) operation)<br />
.getLayoutNodes().listIterator();<br />
if (nodes.hasNext()) {<br />
View node = ((ILayoutNode) nodes.next()).getNode();<br />
Diagram container = node.getDiagram();<br />
if (container == null<br />
|| !(container.getType().equals("Mindmap"))) //$NON-NLS-1$<br />
return false;<br />
}<br />
} else {<br />
return false;<br />
}<br />
IAdaptable layoutHint = ((ILayoutNodeOperation) operation)<br />
.getLayoutHint();<br />
String layoutType = (String) layoutHint.getAdapter(String.class);<br />
return LayoutType.DEFAULT.equals(layoutType);<br />
}<br />
<br />
}<br />
</source><br />
<br />
If you run the diagram using both providers, it's clear that the left-right layout is more well-suited for a mindmap, although some adjustments would be necessary to make it more usable.<br />
<br />
=== Removing Tools from the Palette ===<br />
Let's say you don't want to see the Notes stack and Zoom tool on your palette. To remove them, you need to contribute to the paletteProvider extension-point using the predefinedEntry IDs and remove="true" attribute. For these contributions to not impact all editors, add an editor element with your diagram's ID to the paletteProvider, as seen below:<br />
<br />
<source lang="xml"><br />
<extension point="org.eclipse.gmf.runtime.diagram.ui.paletteProviders"> <br />
<paletteProvider class="org.eclipse.gmf.runtime.diagram.ui.providers.DefaultPaletteProvider"><br />
<Priority name="High"/><br />
<contribution><br />
<predefinedEntry id="standardGroup/zoomTool" remove="true"/><br />
<predefinedEntry id="standardGroup/noteStack/noteTool" remove="true"/> <br />
<predefinedEntry id="standardGroup/noteStack/textTool" remove="true"/> <br />
<predefinedEntry id="standardGroup/noteStack/noteattachmentTool" remove="true"/><br />
</contribution><br />
<editor<br />
id="org.eclipse.gmf.examples.mindmap.diagram.part.MindmapDiagramEditorID"><br />
</editor><br />
</paletteProvider><br />
</extension><br />
</source><br />
<br />
This contribution is added to the org.eclipse.gmf.examples.mindmap.custom plugin.xml file in [http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.gmf/examples/org.eclipse.gmf.examples.mindmap.diagram.custom/plugin.xml?view=log&root=Modeling_Project&pathrev=HEAD CVS].<br />
<br />
=== Customization Extension points reference ===<br />
<br />
Here is the list of extension point you can use in your customization plugins to improve the diagram without modifying the generated code: http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.gmf.doc/reference/extension-points/index.html<br />
<br />
== Customizing generation templates ==<br />
<br />
GMF Tooling uses XPT templates to generate your diagram code. But it offers the way to use alternative template if you have to tweak directly generated code.<br />
<br />
=== Set it up ===<br />
<br />
See http://www.bonitasoft.org/blog/eclipse/customize-your-gmf-editor-by-customizing-templates/<br />
<br />
=== Overriding templates ===<br />
<br />
See http://www.bonitasoft.org/blog/eclipse/customize-your-gmf-editor-by-customizing-templates/<br />
<br />
=== Using aspects ===<br />
<br />
http://www.bonitasoft.org/blog/eclipse/customize-your-gmf-editor-by-customizing-templates/<br />
<br />
== Summary ==<br />
In this section of the tutorial, we saw how to add a composite figure, create a custom action and layout provider contained within a new extension plug-in. In the next section, we will look at using the dashboard, and generating an RCP-based mindmap with the "lite" runtime: [[GMF_Tutorial_Part_4|GMF Tutorial Part 4]]<br />
<br />
== References ==<br />
* [http://www.eclipse.org/modeling/gmp/ Graphical Modeling Project Website]<br />
<br />
* [[Graphical Modeling Framework/Documentation | GMF Documentation]]<br />
<br />
* [[../Part 1 | GMF Tutorial Part 1 - Get Started with GMF]]<br />
<br />
* [[../Part 2 | GMF Tutorial Part 2 - How to configure your editor]]<br />
<br />
* [[../Part 3 | GMF Tutorial Part 3 - Advanced customization]]<br />
<br />
* [[../Part 4 | GMF Tutorial Part 4]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Events&diff=204546Events2010-06-07T04:22:30Z<p>Michael.keppler.gmx.de: fix redirects</p>
<hr />
<div>This page lists conferences, meetings, and events with Eclipse-related presentations, discussions, or whatever. <br />
<br />
__TOC__ <br />
<br />
== Upcoming Events ==<br />
<br />
{| border="1" class="wikitable"<br />
|-<br />
! Conference <br />
! Date <br />
! Where <br />
! Call For Participation <br />
! Notes<br />
|-<br />
| [http://wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010 Eclipse DemoCamps for Helios] <br />
| June 1-30, 2010 <br />
| Worldwide <br />
| [http://wiki.eclipse.org/Eclipse_DemoCamps_Helios_2010 Open for Demos] <br />
| <br><br />
|-<br />
| [http://www-01.ibm.com/software/rational/innovate/ IBM Rational Software Conference] <br />
| June 6-10, 2010 <br />
| Orlando, FL, USA <br />
| [https://www-950.ibm.com/events/rational/rsc2010EMS/ Closed] <br />
| <br><br />
|-<br />
| [http://www.eclipse.dk/arrangements/emf-xtext-og-xpand-for-den-interesserede-dilletant-udi-modelleringens-og-syntaksens-spaendende-verden EMF, Xtext and Xpand for the Interested Amateur] <br />
| June 7, 2010 <br />
| Copenhagen, Denmark <br />
| <br> <br />
| <br><br />
|-<br />
| [http://epicenter.ie/hub-2010.html epicenter] <br />
| June 9-15, 2010 <br />
| Dublin, Ireland <br />
| [http://epicenter.ie/contact.html Closed] <br />
| <br><br />
|-<br />
| [http://www.codegeneration.net/cg2010/ Code Generation] <br />
| June 16-18, 2010 <br />
| Cambridge, United Kingdom <br />
| [http://www.codegeneration.net/cg2010/speak.php Closed] <br />
| <br><br />
|-<br />
| [http://www.cisis.com.cn/en/default.aspx China International Software &amp; Information Fair] <br />
| June 17-20, 2010 <br />
| Dalian, China <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.isqi.org/en/conferences/int-spice-days/2010/ International SPICE Days] <br />
| June 21-23, 2010 <br />
| Stuttgart, Germany <br />
| [http://manage.spice-days.com/openconf.php Closed] <br />
| <br><br />
|-<br />
| [http://ecoop2010.uni-mb.si/ ECOOP] <br />
| June 21-25, 2010 <br />
| Maribor, Slovenia <br />
| [http://ecoop2010.uni-mb.si/important_dates.html Closed] <br />
| <br><br />
|-<br />
| [http://www.jbossworld.com JBoss World] <br />
| June 22-25, 2010 <br />
| Boston, MA, USA <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.omg.org/news/meetings/tc/mn/special-events/Eclipse.htm Symposium on Eclipse OS Software &amp; OMG Open Specs] <br />
| June 23, 2010 <br />
| Minneapolis, Minnesota <br />
| [http://www.omg.org/registration/registration-ws.htm Closed] <br />
| <br><br />
|-<br />
| [[Eclipse Embedded Day Stuttgart 2010]]<br />
| June 24, 2010 <br />
| Stuttgart, Germany <br />
| [http://wiki.eclipse.org/EDay_2010_Call_for_Papers Closed] <br />
| <br><br />
|-<br />
| [http://www.sigs-datacom.de/seacon/seacon.html SEACON] <br />
| June 28-29, 2010 <br />
| Hamburg, Germany <br />
| <br> <br />
| <br><br />
|-<br />
| [http://tools.ethz.ch/ TOOLS Europe] <br />
| June 28-July 2, 2010 <br />
| Malaga, Spain <br />
| [http://cyberchairpro3.borbala.net/toolspapers/submit/ Closed]<br> <br />
| <br><br />
|-<br />
| [http://www.java-forum-stuttgart.de/ Java Forum Stuttgart] <br />
| July 1, 2010 <br />
| Stuttgart, Germany <br />
| [http://www.java-forum-stuttgart.de/cfp.html Closed] <br />
| <br><br />
|-<br />
| [http://www-05.ibm.com/de/events/jazz/ IBM Rational Jazz Roadshow] <br />
| July 6-7, 2010 <br />
| Ehningen & Munich, Germany <br />
| <br> <br />
| <br><br />
|-<br />
| [http://en.oreilly.com/oscon OSCON] <br />
| July 19-23, 2010 <br />
| Portland, OR, USA <br />
| Closed <br />
| <br><br />
|-<br />
| [http://www.embedded.com/esc/india/ ESC India] <br />
| July 21-23,2010 <br />
| Bangalore, India <br />
| Closed <br />
| <br><br />
|-<br />
| [http://www.openexpo.ch/open-source-forum-2010/ Open Source Forum] <br />
| September 1, 2010 <br />
| Zurich, Switzerland <br />
| <br><br />
| <br><br />
|-<br />
| [http://wiki.eclipse.org/EclipseTestingDay2010 Eclipse Testing Day] <br />
| September 8, 2010 <br />
| Darmstadt, Germany <br />
| [http://wiki.eclipse.org/EclipseTestingDay2010_CallForPapers July 2, 2010] <br />
| <br><br />
|-<br />
| [http://www.osspac.com/ OSSPAC] <br />
| September 13-14, 2010 <br />
| Sydney, Australia <br />
| [http://www.osspac.com/schedule-sessions/call-for-papers/ Closed] <br />
| <br><br />
|-<br />
| [http://www.oracle.com/openworld/index.html JavaOne] <br />
| September 19-23, 2010 <br />
| San Francisco, CA, USA <br />
| [https://www28.cplan.com/cfp_prod/CFPLogin.jsp?wId=268225 Closed] <br />
| <br><br />
|-<br />
| [http://www.oracle.com/openworld/index.html Oracle OpenWorld] <br />
| September 19-23, 2010 <br />
| San Francisco, CA, USA <br />
| [http://www.eventreg.com/oracle/openworld2010/sanfrancisco/cfp/ Closed] <br />
| <br><br />
|-<br />
| [http://esc-boston.techinsightsevents.com/ ESC Boston] <br />
| September 20-23, 2010 <br />
| Boston, MA, USA <br />
| [https://www.cmpevents.com/ESCe10/a.asp?option=N&V=3&CPid=286 Closed] <br />
| <br><br />
|-<br />
| [http://www-05.ibm.com/de/events/jazz/ IBM Rational Jazz Roadshow] <br />
| September 21-23, 2010 <br />
| Frankfurt, Dusseldorf & Hamburg, Germany <br />
| <br> <br />
| <br><br />
|-<br />
| [http://openworldforum.org/ Open World Forum] <br />
| September 30-October 1, 2010 <br />
| Paris, France <br />
| [http://owf.ayeba.org/wiki/index.php?title=How_to_submit_a_proposal Closed] <br />
| <br><br />
|-<br />
| [http://www.jaoo.dk/aarhus-2010/conference/ JAOO] <br />
| October 3-6, 2010 <br />
| Aarhus, Denmark <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.agiletestingdays.com/ Agile Testing Days] <br />
| October 4-7, 2010 <br />
| Berlin, Germany <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.spagoworld.org/openevents/ Eclipse SOA/Interoperability Day 2010] <br />
| October 5, 2010 <br />
| Rome, Italy <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.splashcon.org/ Splash] <br />
| October 17-21, 2010 <br />
| Reno, NV, USA <br />
| [http://www.splashcon.org/index.php?option=com_content&view=section&layout=blog&id=1&Itemid=54 Closed] <br />
| <br><br />
|-<br />
| [http://www.osimconference.com/ Open Source in Mobile] <br />
| October 19-20, 2010 <br />
| London, United Kingdom <br />
| <br> <br />
| <br><br />
|-<br />
| [https://www-927.ibm.com/ibm/cas/cascon/index.shtml CASCON] <br />
| November 1-4, 2010 <br />
| Richmond Hill, ON, Canada <br />
| [https://www-927.ibm.com/ibm/cas/cascon/papers.shtml Closed] <br />
| <br><br />
|-<br />
| [http://www.zendcon.com ZendCon] <br />
| November 1-4, 2010 <br />
| Santa Clara, CA, USA <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.eclipsecon.org/summiteurope2010/ Eclipse Summit Europe] <br />
| November 2-4, 2010 <br />
| Ludwigsburg, Germany <br />
| [http://www.eclipsecon.org/summiteurope2010/submissions/?page=submissions August 16, 2010]<br />
| <br><br />
|-<br />
| [http://www.devoxx.com Devoxx] <br />
| November 15-19, 2010 <br />
| Antwerp, Belgium <br />
| <br> <br />
| <br><br />
|-<br />
| [http://www.eclipsecon.org/2011/ EclipseCon] <br />
| March 21-24, 2011 <br />
| Santa Clara, CA, USA <br />
| <br> <br />
| <br><br />
|}<br />
<br />
== Past Events ==<br />
<br />
Links to Eclipsepedia pages about past events: <br />
*[http://wiki.eclipse.org/Eclipse_Banking_Day_Copenhagen Eclipse Banking Day in Copenhagen], June 1, 2010 <br />
*[http://wiki.eclipse.org/EclipseLink/Development/Summit EclipseLink Summit], May 25-27, 2010<br />
*[http://www.eclipseday.in Eclipse Day India], April 23, 2010 <br />
*[[Eclipse DemoCamps November 2009|Eclipse DemoCamps]], November-December, 2009 <br />
*[[EclipseRT Day|EclipseRT Day in Toronto]], November 19, 2009 <br />
*[[Eclipse Modeling Day|Eclipse Modeling Day in Toronto]], November 18, 2009 <br />
*[[EclipseRT Day|EclipseRT Day in Austin]], November 17, 2009 <br />
*[[Eclipse Modeling Day|Eclipse Modeling Day in New York]], November 16, 2009 <br />
*[[EclipseInsuranceDayCologne|Eclipse Insurance Day]], September 30, 2009 <br />
*[[Eclipse Day At Googleplex 2009|Eclipse Day at the Googleplex]], August 27, 2009 <br />
*[[EclipseApplicationDeveloperDayKarlsruhe|Eclipse Application Developer Day Karlsruhe]], July 7, 2009 <br />
*[[Eclipse Embedded Day Stuttgart 2009]], June 25, 2009 <br />
*[[Eclipse DemoCamps Galileo 2009|Eclipse DemoCamps]], June, 2009 <br />
*[[EclipseBankingDayLondon|Eclipse Banking Day in London]], February 12, 2009 <br />
*[[EclipseBankingDayNYC|Eclipse Banking Day in NYC]], December 9, 2008 <br />
*[[Eclipse Summit Europe 2008 Hackathon]], November 19-20, 2008 <br />
*[[Eclipse DemoCamps November 2008|Eclipse DemoCamps]], November, 2008 <br />
*[[CDT/summitfall2008|CDT Summit]], September 23-26, 2008 <br />
*[[EclipseDay At Googleplex|Eclipse Day at the Googleplex]], June 24, 2008 <br />
*[[Eclipse DemoCamps 2008 - Ganymede Edition|Eclipse DemoCamps]], June 1-30, 2008 <br />
*[[E4/Summit|E4 Summit]], May 22-23, 2008 <br />
*[[Eclipse Summit on Runtime Technologies and Platforms|Eclipse Runtime Summit]], December 11, 2007 <br />
*[[Eclipse DemoCamps 2007]], November-December, 2007 <br />
*[[Eclipse Summit Europe 2007 RCP Experience Workshop|RCP Experience Workshop]], October 9, 2007 <br />
*[http://tdd.microdoc.com Test-Driven Development Forum], October 9, 2007 <br />
*[[CDT/summitfall2007|CDT Summit]], September 25-27, 2007 <br />
*[[Equinox Summit 2007|Equinox Summit]], Sep. 25-26, 2007 <br />
*[[Ganymede Provisioning Workshop]], April 10-11, 2007 <br />
*[[PluginFest 2007]], January 23-24, 2007 <br />
*[[Europa Build Workshop]], September 12-13, 2006<br />
<br />
== Eclipse Training Classes ==<br />
<br />
[[Training Schedule|See a current schedule of Eclipse training classes taught by Foundation member companies.]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Eclipse_Embedded_Day_Stuttgart_2010&diff=204545Eclipse Embedded Day Stuttgart 20102010-06-07T04:21:42Z<p>Michael.keppler.gmx.de: /* Past events */ fix link</p>
<hr />
<div>[[Image:Eday2010.JPG|EDay 2010]]<br />
<br />
== Want to learn more about Eclipse in the embedded space ? ==<br />
''09:00-18:00 June 24, 2010, Stuttgart''<br />
<br />
MicroDoc presents the second Eclipse Embedded Day called '''EDay 2010''' in Stuttgart in cooperation with the Eclipse Foundation and [http://www.region-stuttgart.de Wirtschaftsförderung Region Stuttgart]. Senior technical developers, architects and technical managers will learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. <br />
<br />
The agenda will be packed with high value talks about Eclipse technologies for the embedded space (mobile, automotive, telematics, consumer electonics, medical etc.). Parallel sessions on Eclipse embedded projects and interesting case studies will complement the strategic presentations.<br />
<br />
There's a unique opportunity for the attendees from the automotive sector to visit '''EDay 2010''' and [http://www.open-forum.net/ Open Forum 2010: International SPICE Days, Automotive Safety & Security and A2A - Apps to Automotive] the days before at the same location. <br />
<br />
Last year the [http://wiki.eclipse.org/EclipseEmbeddedDayStgt EDay 2009] had over 100 registrations. So if you are working in the embedded space, hurry up and [http://embeddedday2010.eventbrite.com/ register for this free event], space is limited. Please notice, that [http://www.open-forum.net/ Open Forum 2010] has got its own registration and is not for free.<br />
<br />
We look forward to meeting you at '''EDay 2010''' !<br />
<br />
- Your [mailto:eday@microdoc.com EDay Team]<br />
<br />
=== Date & Location ===<br />
June 24, 2010<br />
8:30am - 6:00pm<br />
<br />
[http://www.hausderwirtschaft.de Haus der Wirtschaft Baden-Württemberg]<br />
<br>Willi-Bleicher-Str. 19 <br><br />
70174 Stuttgart <br><br />
Germany<br />
<br />
[http://www.hausderwirtschaft.de/anfahrt/214011.html Getting there ...]<br />
<br />
===Registration===<br />
<br />
'''EDay 2010''' is free of charge but space is limited ! Please register via [http://embeddedday2010.eventbrite.com EDay 2010 Eventbrite site].<br />
<br />
<br />
<br />
== Cooperation Partners ==<br />
<br />
[[Image:Eclipse.JPG|Eclipse]] [[Image:Microdoc.gif|MicroDoc]] [[Image:osrs-logo.gif|Opensource Region Stuttgart]] [[Image:wrs-logo.gif|Wirtschaftsfoerderung Region Stuttgart]] [[Image:OSBF-Logo.gif|150px|Open Source Business Foundation]] [[Image:ES1.jpg|Eclipse Source]]<br />
<br />
== Media Partners ==<br />
<br />
[[Image:EP_Logo.jpg|Elektronikpraxis]] [[Image:Dpunkt.logo_dunkel.jpg|dPunkt Verlag]]<br />
<br />
== Sponsors ==<br />
<br />
'''Be a Sponsor'''<br />
<br />
If you'd like to learn more about sponsoring '''EDay 2010''' you'll find more information about sponsorship in our [http://wiki.eclipse.org/EDay_2010_Call_for_Sponsors EDay 2010 Call for Sponsors].<br />
<br />
<br />
== Agenda ==<br />
<br />
<br><br />
<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 8:30 - 9:00 || colspan="2" align="center" | Registration <br />
|-<br />
<br />
|-<br />
| 9:00 - 9:15 || colspan="2" align="center" | Introduction <br />
|-<br />
<br />
|-<br />
| 9:15-10:00 || colspan="2" align="center" | [[/SessionAbstracts#Sphinx_.E2.80.93_an_Industrial_Strength_Tool_Platform_Fostering_Model-driven_Development_of_Embedded_Systems|Sphinx – an Industrial Strength Tool Platform Fostering Model-driven Development of Embedded Systems]]<br />
Dr. Stephan Eberle, Geensys <br />
|-<br />
<br />
|-<br />
| 10:15-11:00<br />
| [[/SessionAbstracts#Visual_Tools_for_Analysis_of_Embedded_Applications|Visual Tools for Analysis of Embedded Applications]]<br />
Dr. Fridtjof Siebert (CTO, aicas GmbH, Germany)<br />
| [[/SessionAbstracts#Building_Validation_Suites_with_Eclipse_for_Model-based_Generation_Tools|Building Validation Suites with Eclipse for Model-based Generation Tools ]]<br />
Dr. Oscar Slotosch (CEO, Validas AG)<br />
|-<br />
<br />
|-<br />
| 11:00-11:30 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 11:30-12:15 <br />
| [[/SessionAbstracts#Development_Organisations_of_the_Future|Development Organisations of the Future]]<br />
Hans-Jürgen Kugler (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#eTrice:_a_proposed_Eclipse_project_for_embedded_MDD_based_on_ROOM|eTrice: a proposed Eclipse project for embedded MDD based on ROOM]]<br />
Thomas Schuetz (CEO, Protos Software)<br />
|-<br />
<br />
|-<br />
| 12:15-13:15 || colspan="2" align="center" | Lunch<br />
|-<br />
<br />
|-<br />
| 13:15-14:00<br />
| [[/SessionAbstracts#Developing_Smart_Home_Systems_by_using_OSGi_and_Plug_Computers|Developing Smart Home Systems by using OSGi and Plug Computers]]<br />
Dimitar Valtchev (CTO, ProSyst Software GmbH)<br />
| [[/SessionAbstracts#Scaling_configuration_management:__from_single_embedded_device_deployment_to_fully_customized_multi-customer.2C_multi-device_software._A_case_study|Scaling configuration management: from single embedded device deployment to fully customized multi-customer, multi-device software. A case study ]]<br />
George Mesesan (Senior Software Engineer, MicroDoc GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 14:00-14:45 <br />
| [[/SessionAbstracts#Documentation_of_Eclipse_applications_with_DITA|Documentation of Eclipse applications with DITA]]<br />
Gunthilde Sohn (instinctools GmbH)<br />
| [[/SessionAbstracts#Lessons_Learned_und_die_Vorteile_des_Einsatzes_von_textuellen_dom.C3.A4nenspezifischen_Modellen_auf_Basis_von_Open_Source-Tools|Lessons Learned und die Vorteile des Einsatzes von textuellen domänenspezifischen Modellen auf Basis von Open Source-Tools ]]<br />
Andreas Graf (itemisAG)<br />
|-<br />
<br />
|-<br />
| 14:45-15:00 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 15:00-15:45 <br />
| [[/SessionAbstracts#Frischer_Wind_aus_der_Linux_community_umweht_embedded_Software_Entwickler|Frischer Wind aus der Linux community umweht embedded Software Entwickler]]<br />
Janos Koppany (CEO, Intland Software GmbH)<br />
| [[/SessionAbstracts#Testing_embedded_graphical_user_interfaces_.E2.80.93_friend_or_foe.3F|Testing embedded graphical user interfaces – friend or foe?]]<br />
Markus Tiede (BREDEX GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 15:45-16:30 <br />
| [[/SessionAbstracts#Functional_Safety_Implications_for_Development_Infrastructures|Functional Safety Implications for Development Infrastructures]]<br />
Dr. Erwin Petry (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#Morpheus:_the_first_telematics_IDE_based_on_Eclipse|Morpheus: the first telematics IDE based on Eclipse]]<br />
Nicolas Desprès <br />
|-<br />
<br />
|-<br />
|}<br />
<br />
== Contact ==<br />
For more information email [mailto:eday@microdoc.com EDay Team]<br />
<br />
== Past events ==<br />
[[Eclipse Embedded Day Stuttgart 2009]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Eclipse_Embedded_Day_Stuttgart_2010&diff=204543Eclipse Embedded Day Stuttgart 20102010-06-07T04:19:45Z<p>Michael.keppler.gmx.de: EclipseEmbeddedDayStgt2010 moved to Eclipse Embedded Day Stuttgart 2010: search does not work for such titles</p>
<hr />
<div>[[Image:Eday2010.JPG|EDay 2010]]<br />
<br />
== Want to learn more about Eclipse in the embedded space ? ==<br />
''09:00-18:00 June 24, 2010, Stuttgart''<br />
<br />
MicroDoc presents the second Eclipse Embedded Day called '''EDay 2010''' in Stuttgart in cooperation with the Eclipse Foundation and [http://www.region-stuttgart.de Wirtschaftsförderung Region Stuttgart]. Senior technical developers, architects and technical managers will learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. <br />
<br />
The agenda will be packed with high value talks about Eclipse technologies for the embedded space (mobile, automotive, telematics, consumer electonics, medical etc.). Parallel sessions on Eclipse embedded projects and interesting case studies will complement the strategic presentations.<br />
<br />
There's a unique opportunity for the attendees from the automotive sector to visit '''EDay 2010''' and [http://www.open-forum.net/ Open Forum 2010: International SPICE Days, Automotive Safety & Security and A2A - Apps to Automotive] the days before at the same location. <br />
<br />
Last year the [http://wiki.eclipse.org/EclipseEmbeddedDayStgt EDay 2009] had over 100 registrations. So if you are working in the embedded space, hurry up and [http://embeddedday2010.eventbrite.com/ register for this free event], space is limited. Please notice, that [http://www.open-forum.net/ Open Forum 2010] has got its own registration and is not for free.<br />
<br />
We look forward to meeting you at '''EDay 2010''' !<br />
<br />
- Your [mailto:eday@microdoc.com EDay Team]<br />
<br />
=== Date & Location ===<br />
June 24, 2010<br />
8:30am - 6:00pm<br />
<br />
[http://www.hausderwirtschaft.de Haus der Wirtschaft Baden-Württemberg]<br />
<br>Willi-Bleicher-Str. 19 <br><br />
70174 Stuttgart <br><br />
Germany<br />
<br />
[http://www.hausderwirtschaft.de/anfahrt/214011.html Getting there ...]<br />
<br />
===Registration===<br />
<br />
'''EDay 2010''' is free of charge but space is limited ! Please register via [http://embeddedday2010.eventbrite.com EDay 2010 Eventbrite site].<br />
<br />
<br />
<br />
== Cooperation Partners ==<br />
<br />
[[Image:Eclipse.JPG|Eclipse]] [[Image:Microdoc.gif|MicroDoc]] [[Image:osrs-logo.gif|Opensource Region Stuttgart]] [[Image:wrs-logo.gif|Wirtschaftsfoerderung Region Stuttgart]] [[Image:OSBF-Logo.gif|150px|Open Source Business Foundation]] [[Image:ES1.jpg|Eclipse Source]]<br />
<br />
== Media Partners ==<br />
<br />
[[Image:EP_Logo.jpg|Elektronikpraxis]] [[Image:Dpunkt.logo_dunkel.jpg|dPunkt Verlag]]<br />
<br />
== Sponsors ==<br />
<br />
'''Be a Sponsor'''<br />
<br />
If you'd like to learn more about sponsoring '''EDay 2010''' you'll find more information about sponsorship in our [http://wiki.eclipse.org/EDay_2010_Call_for_Sponsors EDay 2010 Call for Sponsors].<br />
<br />
<br />
== Agenda ==<br />
<br />
<br><br />
<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 8:30 - 9:00 || colspan="2" align="center" | Registration <br />
|-<br />
<br />
|-<br />
| 9:00 - 9:15 || colspan="2" align="center" | Introduction <br />
|-<br />
<br />
|-<br />
| 9:15-10:00 || colspan="2" align="center" | [[/SessionAbstracts#Sphinx_.E2.80.93_an_Industrial_Strength_Tool_Platform_Fostering_Model-driven_Development_of_Embedded_Systems|Sphinx – an Industrial Strength Tool Platform Fostering Model-driven Development of Embedded Systems]]<br />
Dr. Stephan Eberle, Geensys <br />
|-<br />
<br />
|-<br />
| 10:15-11:00<br />
| [[/SessionAbstracts#Visual_Tools_for_Analysis_of_Embedded_Applications|Visual Tools for Analysis of Embedded Applications]]<br />
Dr. Fridtjof Siebert (CTO, aicas GmbH, Germany)<br />
| [[/SessionAbstracts#Building_Validation_Suites_with_Eclipse_for_Model-based_Generation_Tools|Building Validation Suites with Eclipse for Model-based Generation Tools ]]<br />
Dr. Oscar Slotosch (CEO, Validas AG)<br />
|-<br />
<br />
|-<br />
| 11:00-11:30 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 11:30-12:15 <br />
| [[/SessionAbstracts#Development_Organisations_of_the_Future|Development Organisations of the Future]]<br />
Hans-Jürgen Kugler (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#eTrice:_a_proposed_Eclipse_project_for_embedded_MDD_based_on_ROOM|eTrice: a proposed Eclipse project for embedded MDD based on ROOM]]<br />
Thomas Schuetz (CEO, Protos Software)<br />
|-<br />
<br />
|-<br />
| 12:15-13:15 || colspan="2" align="center" | Lunch<br />
|-<br />
<br />
|-<br />
| 13:15-14:00<br />
| [[/SessionAbstracts#Developing_Smart_Home_Systems_by_using_OSGi_and_Plug_Computers|Developing Smart Home Systems by using OSGi and Plug Computers]]<br />
Dimitar Valtchev (CTO, ProSyst Software GmbH)<br />
| [[/SessionAbstracts#Scaling_configuration_management:__from_single_embedded_device_deployment_to_fully_customized_multi-customer.2C_multi-device_software._A_case_study|Scaling configuration management: from single embedded device deployment to fully customized multi-customer, multi-device software. A case study ]]<br />
George Mesesan (Senior Software Engineer, MicroDoc GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 14:00-14:45 <br />
| [[/SessionAbstracts#Documentation_of_Eclipse_applications_with_DITA|Documentation of Eclipse applications with DITA]]<br />
Gunthilde Sohn (instinctools GmbH)<br />
| [[/SessionAbstracts#Lessons_Learned_und_die_Vorteile_des_Einsatzes_von_textuellen_dom.C3.A4nenspezifischen_Modellen_auf_Basis_von_Open_Source-Tools|Lessons Learned und die Vorteile des Einsatzes von textuellen domänenspezifischen Modellen auf Basis von Open Source-Tools ]]<br />
Andreas Graf (itemisAG)<br />
|-<br />
<br />
|-<br />
| 14:45-15:00 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 15:00-15:45 <br />
| [[/SessionAbstracts#Frischer_Wind_aus_der_Linux_community_umweht_embedded_Software_Entwickler|Frischer Wind aus der Linux community umweht embedded Software Entwickler]]<br />
Janos Koppany (CEO, Intland Software GmbH)<br />
| [[/SessionAbstracts#Testing_embedded_graphical_user_interfaces_.E2.80.93_friend_or_foe.3F|Testing embedded graphical user interfaces – friend or foe?]]<br />
Markus Tiede (BREDEX GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 15:45-16:30 <br />
| [[/SessionAbstracts#Functional_Safety_Implications_for_Development_Infrastructures|Functional Safety Implications for Development Infrastructures]]<br />
Dr. Erwin Petry (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#Morpheus:_the_first_telematics_IDE_based_on_Eclipse|Morpheus: the first telematics IDE based on Eclipse]]<br />
Nicolas Desprès <br />
|-<br />
<br />
|-<br />
|}<br />
<br />
== Contact ==<br />
For more information email [mailto:eday@microdoc.com EDay Team]<br />
<br />
== Past events ==<br />
[http://wiki.eclipse.org/EclipseEmbeddedDayStgt|Eclipse Embedded Day Stuttgart 2009]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EclipseEmbeddedDayStgt2010&diff=204544EclipseEmbeddedDayStgt20102010-06-07T04:19:45Z<p>Michael.keppler.gmx.de: EclipseEmbeddedDayStgt2010 moved to Eclipse Embedded Day Stuttgart 2010: search does not work for such titles</p>
<hr />
<div>#REDIRECT [[Eclipse Embedded Day Stuttgart 2010]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Eclipse_Embedded_Day_Stuttgart_2010&diff=204542Eclipse Embedded Day Stuttgart 20102010-06-07T04:19:19Z<p>Michael.keppler.gmx.de: link to 2009</p>
<hr />
<div>[[Image:Eday2010.JPG|EDay 2010]]<br />
<br />
== Want to learn more about Eclipse in the embedded space ? ==<br />
''09:00-18:00 June 24, 2010, Stuttgart''<br />
<br />
MicroDoc presents the second Eclipse Embedded Day called '''EDay 2010''' in Stuttgart in cooperation with the Eclipse Foundation and [http://www.region-stuttgart.de Wirtschaftsförderung Region Stuttgart]. Senior technical developers, architects and technical managers will learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. <br />
<br />
The agenda will be packed with high value talks about Eclipse technologies for the embedded space (mobile, automotive, telematics, consumer electonics, medical etc.). Parallel sessions on Eclipse embedded projects and interesting case studies will complement the strategic presentations.<br />
<br />
There's a unique opportunity for the attendees from the automotive sector to visit '''EDay 2010''' and [http://www.open-forum.net/ Open Forum 2010: International SPICE Days, Automotive Safety & Security and A2A - Apps to Automotive] the days before at the same location. <br />
<br />
Last year the [http://wiki.eclipse.org/EclipseEmbeddedDayStgt EDay 2009] had over 100 registrations. So if you are working in the embedded space, hurry up and [http://embeddedday2010.eventbrite.com/ register for this free event], space is limited. Please notice, that [http://www.open-forum.net/ Open Forum 2010] has got its own registration and is not for free.<br />
<br />
We look forward to meeting you at '''EDay 2010''' !<br />
<br />
- Your [mailto:eday@microdoc.com EDay Team]<br />
<br />
=== Date & Location ===<br />
June 24, 2010<br />
8:30am - 6:00pm<br />
<br />
[http://www.hausderwirtschaft.de Haus der Wirtschaft Baden-Württemberg]<br />
<br>Willi-Bleicher-Str. 19 <br><br />
70174 Stuttgart <br><br />
Germany<br />
<br />
[http://www.hausderwirtschaft.de/anfahrt/214011.html Getting there ...]<br />
<br />
===Registration===<br />
<br />
'''EDay 2010''' is free of charge but space is limited ! Please register via [http://embeddedday2010.eventbrite.com EDay 2010 Eventbrite site].<br />
<br />
<br />
<br />
== Cooperation Partners ==<br />
<br />
[[Image:Eclipse.JPG|Eclipse]] [[Image:Microdoc.gif|MicroDoc]] [[Image:osrs-logo.gif|Opensource Region Stuttgart]] [[Image:wrs-logo.gif|Wirtschaftsfoerderung Region Stuttgart]] [[Image:OSBF-Logo.gif|150px|Open Source Business Foundation]] [[Image:ES1.jpg|Eclipse Source]]<br />
<br />
== Media Partners ==<br />
<br />
[[Image:EP_Logo.jpg|Elektronikpraxis]] [[Image:Dpunkt.logo_dunkel.jpg|dPunkt Verlag]]<br />
<br />
== Sponsors ==<br />
<br />
'''Be a Sponsor'''<br />
<br />
If you'd like to learn more about sponsoring '''EDay 2010''' you'll find more information about sponsorship in our [http://wiki.eclipse.org/EDay_2010_Call_for_Sponsors EDay 2010 Call for Sponsors].<br />
<br />
<br />
== Agenda ==<br />
<br />
<br><br />
<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 8:30 - 9:00 || colspan="2" align="center" | Registration <br />
|-<br />
<br />
|-<br />
| 9:00 - 9:15 || colspan="2" align="center" | Introduction <br />
|-<br />
<br />
|-<br />
| 9:15-10:00 || colspan="2" align="center" | [[/SessionAbstracts#Sphinx_.E2.80.93_an_Industrial_Strength_Tool_Platform_Fostering_Model-driven_Development_of_Embedded_Systems|Sphinx – an Industrial Strength Tool Platform Fostering Model-driven Development of Embedded Systems]]<br />
Dr. Stephan Eberle, Geensys <br />
|-<br />
<br />
|-<br />
| 10:15-11:00<br />
| [[/SessionAbstracts#Visual_Tools_for_Analysis_of_Embedded_Applications|Visual Tools for Analysis of Embedded Applications]]<br />
Dr. Fridtjof Siebert (CTO, aicas GmbH, Germany)<br />
| [[/SessionAbstracts#Building_Validation_Suites_with_Eclipse_for_Model-based_Generation_Tools|Building Validation Suites with Eclipse for Model-based Generation Tools ]]<br />
Dr. Oscar Slotosch (CEO, Validas AG)<br />
|-<br />
<br />
|-<br />
| 11:00-11:30 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 11:30-12:15 <br />
| [[/SessionAbstracts#Development_Organisations_of_the_Future|Development Organisations of the Future]]<br />
Hans-Jürgen Kugler (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#eTrice:_a_proposed_Eclipse_project_for_embedded_MDD_based_on_ROOM|eTrice: a proposed Eclipse project for embedded MDD based on ROOM]]<br />
Thomas Schuetz (CEO, Protos Software)<br />
|-<br />
<br />
|-<br />
| 12:15-13:15 || colspan="2" align="center" | Lunch<br />
|-<br />
<br />
|-<br />
| 13:15-14:00<br />
| [[/SessionAbstracts#Developing_Smart_Home_Systems_by_using_OSGi_and_Plug_Computers|Developing Smart Home Systems by using OSGi and Plug Computers]]<br />
Dimitar Valtchev (CTO, ProSyst Software GmbH)<br />
| [[/SessionAbstracts#Scaling_configuration_management:__from_single_embedded_device_deployment_to_fully_customized_multi-customer.2C_multi-device_software._A_case_study|Scaling configuration management: from single embedded device deployment to fully customized multi-customer, multi-device software. A case study ]]<br />
George Mesesan (Senior Software Engineer, MicroDoc GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 14:00-14:45 <br />
| [[/SessionAbstracts#Documentation_of_Eclipse_applications_with_DITA|Documentation of Eclipse applications with DITA]]<br />
Gunthilde Sohn (instinctools GmbH)<br />
| [[/SessionAbstracts#Lessons_Learned_und_die_Vorteile_des_Einsatzes_von_textuellen_dom.C3.A4nenspezifischen_Modellen_auf_Basis_von_Open_Source-Tools|Lessons Learned und die Vorteile des Einsatzes von textuellen domänenspezifischen Modellen auf Basis von Open Source-Tools ]]<br />
Andreas Graf (itemisAG)<br />
|-<br />
<br />
|-<br />
| 14:45-15:00 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 15:00-15:45 <br />
| [[/SessionAbstracts#Frischer_Wind_aus_der_Linux_community_umweht_embedded_Software_Entwickler|Frischer Wind aus der Linux community umweht embedded Software Entwickler]]<br />
Janos Koppany (CEO, Intland Software GmbH)<br />
| [[/SessionAbstracts#Testing_embedded_graphical_user_interfaces_.E2.80.93_friend_or_foe.3F|Testing embedded graphical user interfaces – friend or foe?]]<br />
Markus Tiede (BREDEX GmbH)<br />
|-<br />
<br />
<br />
|-<br />
| 15:45-16:30 <br />
| [[/SessionAbstracts#Functional_Safety_Implications_for_Development_Infrastructures|Functional Safety Implications for Development Infrastructures]]<br />
Dr. Erwin Petry (KUGLER MAAG CIE GmbH)<br />
| [[/SessionAbstracts#Morpheus:_the_first_telematics_IDE_based_on_Eclipse|Morpheus: the first telematics IDE based on Eclipse]]<br />
Nicolas Desprès <br />
|-<br />
<br />
|-<br />
|}<br />
<br />
== Contact ==<br />
For more information email [mailto:eday@microdoc.com EDay Team]<br />
<br />
== Past events ==<br />
[http://wiki.eclipse.org/EclipseEmbeddedDayStgt|Eclipse Embedded Day Stuttgart 2009]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Eclipse_Embedded_Day_Stuttgart_2009&diff=204540Eclipse Embedded Day Stuttgart 20092010-06-07T04:18:48Z<p>Michael.keppler.gmx.de: EclipseEmbeddedDayStgt moved to Eclipse Embedded Day Stuttgart 2009: search doesn't work for such titles</p>
<hr />
<div>== Eclipse Embedded Day in Stuttgart == <br />
[[Image:Eday-banner.jpg]]<br />
<br />
Eclipse Embedded Day is a day-long event for senior technical developers, architects and technical managers in the automotive, telematics, mobile, consumer electronic and medical industry to learn how to better leverage Eclipse technology and the Eclipse community as part of their development strategy. In addition the event features sessions on Eclipse projects related to the embedded space and case studies of automotive, telematics, mobile, medical, consumer electronic institutions. The event will focus on three themes: <br />
# Eclipse as a platform for application development in the embedded space; <br />
# Collaborating with the open source community, Working Groups; <br />
# Case studies of projects of companies in the automotive, telematics, medical or consumer electronics area<br />
<br />
Attendees will have the chance to hear speakers from leading companies in the embedded space and experts from the Eclipse community. There is no cost to attend but [[#Attendee Registration|pre-registration]] is required. <br />
<br />
You can also follow the event on [http://twitter.com/eclipseeday Twitter]<br />
<br />
=== Date & Location ===<br />
June 25, 2009<br />
8:30am - 5:30pm<br />
<br />
Note: this is intentionally directly after the [http://www.isqi.org/en/conferences/spice-days/2009/ SPICE Days], at the same location<br />
<br />
[http://www.sportstuttgart.de SpOrt Stuttgart] <br><br />
<br />
Sport, Bildungs- und Dienstleistungszentrum GbR <br />
<br>Fritz-Walter-Weg 19 <br><br />
70372 Stuttgart <br><br />
<br />
[[Image:sportStuttgart.jpg]]<br />
<br />
[http://www.sportstuttgart.de/cms/iwebs/default.aspx?mmid=826&smid=2037 Getting there ...]<br />
<br />
<br />
<br />
== Sponsors ==<br />
<br />
[[Image:Eclipse.JPG|Eclipse]] [[Image:Microdoc.gif|MicroDoc]] [[Image:BandXI_3.GIF|BandXI]] [[Image:itemis.gif|Itemis]] [[Image:ES1.jpg|Eclipse Source]]<br />
<br />
<br><br />
<br />
== Media Partner ==<br />
<br />
[[Image:Dpunkt.logo_dunkel.jpg|dPunkt Verlag]] [[Image:osrs-logo.gif|Opensource Region Stuttgart]] [[Image:wrs-logo.gif|Wirtschaftsfoerderung Region Stuttgart]] [[Image:EP_Logo.jpg|Elektronikpraxis]]<br />
<br><br />
<br />
== Embedded Day in the Media ==<br />
# heise.de Veranstaltungsberichte: [http://www.heise.de/developer/Eclipse-Embedded-Day-Entwicklungsumgebung-in-der-Embedded-Welt-angekommen--/artikel/141227 Eclipse Embedded Day: Entwicklungsumgebung in der Embedded-Welt angekommen]<br />
# Eclipse Community Bulletin: [http://www.eclipse.org/org/press-release/20090504_embeddedday.php Eclipse Embedded Day in Stuttgart]<br />
# Elektronikpraxis.de: [http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/implementierung/articles/186198/?cmp=beleg-link| Veranstaltungshinweis: Eclipse Member lädt zum Embedded Day nach Stuttgart]<br />
# it republik>>JAXenter: [http://it-republik.de/jaxenter/news/Eclipse-Embedded-Day-048668.html| Eclipse Embedded Day]<br />
# heise.de: [http://www.heise.de/newsticker/Eclipse-Embedded-Day-am-25-Juni-in-Stuttgart--/meldung/126846| Eclipse Embedded Day am 25. Juni in Stuttgart]<br />
<br />
<br><br />
<br />
== Agenda ==<br />
<br><br />
<br />
{| class="wikitable" border="1" cellpadding="2"<br />
! Time !! Track 1 !! Track 2 <br />
<br />
|-<br />
| 8:30 - 9:00 || colspan="2" align="center" | Registration <br />
|-<br />
<br />
|-<br />
| 9:00 - 9:15 || colspan="2" align="center" | Introduction - Ralph Müller (Director, Ecosystem - Europe, Eclipse Foundation) - [http://wiki.eclipse.org/images/3/3b/2009-06-25_Eclipse_Embedded_Day_Stuttgart.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 9:15-10:00 || colspan="2" align="center" |<br />
[[/SessionAbstracts#Provisioning and managing embedded systems|Provisioning and managing embedded systems]] <br> <br />
Jochen Krause (EclipseSource) - [http://wiki.eclipse.org/images/1/14/P2_for_embedded.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 10:15-10:45 || <br />
[[/SessionAbstracts#Managing Open Source Legal Issues|Managing Open Source Legal Issues]] <br><br />
Janet Campbell (Legal Counsel, Intellectual Property, Eclipse Foundation) - [http://wiki.eclipse.org/images/e/e1/Eclipse_Embedded_Day_June_2009.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#Profiling Java Applications Running on Embedded Devices with Restricted Resources|Profiling Java Applications Running on Embedded Devices with Restricted Resources]] <br> <br />
Dr. Dimitar Valtchev (CTO, ProSyst Software GmbH) - [http://wiki.eclipse.org/images/7/76/ProfilingJavaEmbeddedDevices.pdf Slides (pdf)] [http://live.eclipse.org/node/781 Video]<br />
|-<br />
<br />
|-<br />
| 10:45-11:15 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 11:15-11:45 || <br />
[[/SessionAbstracts#Distributed Embedded Systems with Ambicomp|Distributed Embedded Systems with Ambicomp]] <br><br />
Johannes Eickhold (Technical University of Munich and Karlsruhe) - [http://wiki.eclipse.org/images/4/40/Ambicomp.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#The interplay between Models, Generators and Variants|The interplay between Models, Generators and Variants]] <br><br />
Markus Völter, Andreas Graf (itemis AG) - [http://wiki.eclipse.org/images/1/1e/EclipseEmbDaySttgt_VoelterGraf.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 12:00-12:30 || <br />
[[/SessionAbstracts#How Mature are Maturity Models?|How Mature are Maturity Models?]] <br><br />
Hans-Jürgen Kugler (Chief Scientist, KUGLER MAAG CIE GmbH) - [http://wiki.eclipse.org/images/3/36/20090625A_Eclipse_Maturity_Models.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#Device Emulation with OSGi and Flash|Device Emulation with OSGi and Flash]] <br><br />
Marcus Harringer (MicroDoc Computersysteme GmbH) - [http://wiki.eclipse.org/images/7/78/Device-emulation_edays.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 12:30-13:30 || colspan="2" align="center" | Lunch <br />
|-<br />
<br />
|-<br />
| 13:30-14:00 || <br />
[[/SessionAbstracts#An open OSGI Embedded platform for Intelligent Transport|An open OSGI Embedded platform for Intelligent Transport]] <br><br />
Eliane Fourgeau (VP Marketing, Geensys SAS) - [http://wiki.eclipse.org/images/b/bd/Geensys-Enove-Stuttgart_june25_2009_V1.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#Building an embedded software IDE on top of Eclipse|Building an embedded software IDE on top of Eclipse]] <br><br />
Gaetan Morice (Anyware Technologies), David Pochet (Wavecom) - [http://wiki.eclipse.org/images/2/27/Embedded_ide.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 14:15-14:45 || <br />
[[/SessionAbstracts#Open-DO and OSEE: agile methods for producing high-integrity software|Open-DO and OSEE: agile methods for producing high-integrity software]] <br><br />
Nicolas Setton (Adacore) - [http://wiki.eclipse.org/images/c/cb/Open-DO_OSEE.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#Nutzen und Grenzen der Erweiterbarkeit von Eclipse CDT (ein Erfahrungsbericht)|Nutzen und Grenzen der Erweiterbarkeit von Eclipse CDT (ein Erfahrungsbericht)]] <br><br />
Harald Kästel-Baumgartner (Bosch Rexroth, The Drive & Control Company, Electric Drives and Controls) - [http://wiki.eclipse.org/images/5/5a/CDT_at_Rexroth.pdf Slides (pdf)] [http://live.eclipse.org/node/784 Video]<br />
|-<br />
<br />
|-<br />
| 14:45-15:15 || colspan="2" align="center" | Break<br />
|-<br />
<br />
|-<br />
| 15:15-15:45 || <br />
[[/SessionAbstracts#OSGi: The Best Tool in Your Embedded Systems Toolbox|OSGi: The Best Tool in Your Embedded Systems Toolbox]] ([http://www.slideshare.net/bretth/eclipseembeddedday2009osgi-best-tool-in-your-embedded-systems-toolbox slides]) <br><br />
James Branigan, Brett Hackleman (Band XI International) <br />
|| <br />
[[/SessionAbstracts#Eclipse-based IS2T Embedded Tools allow new design concept: Drag Emb'Drop|Eclipse-based IS2T Embedded Tools allow new design concept: Drag Emb'Drop]] <br><br />
Emmanuel Vertongen (IS2T) - [http://wiki.eclipse.org/images/5/5d/IS2T-ECLIPSE.pdf Slides (pdf)]<br />
|-<br />
<br />
|-<br />
| 16:00-16:30 || <br />
[[/SessionAbstracts#Artop – a shared platform for AUTOSAR tool development|Artop – a shared platform for AUTOSAR tool development]] <br><br />
Christian Knüchel (BMW Car IT) - [http://wiki.eclipse.org/images/8/84/Autosar_Artop_Slides.pdf Slides (pdf)]<br />
|| <br />
[[/SessionAbstracts#99,99% Testautomation using OSGi, Eclipse and FitNesse|99,99% Testautomation using OSGi, Eclipse and FitNesse<br />
]] <br><br />
Martin Figel (Daimler FleetBoard GmbH)<br />
|-<br />
<br />
|-<br />
| 16:45-17:15 || colspan="2" align="center" | Closing Keynote - Dave Thomas (Bedarra Research Labs)<br />
|-<br />
<br />
|-<br />
| colspan="3" align="center" | Networking with free beer sponsored by [[Image:ES1.jpg|px150]]<br />
|-<br />
<br />
|-<br />
|}<br />
<br />
<br />
[[EclipseEmbeddedDayStgt/SessionAbstracts | All Session Abstracts]]<br />
<br />
== Attendee Registration ==<br />
All attendees must pre-register for this event. '''NOTE: Registration is now closed!''' <br />
<br />
There is the possibility to register on a waiting list, please send an e-mail to [mailto:cbo@microdoc.com Christine Mitterbauer]<br />
<br />
=== Registered Attendees ===<br />
# Ralph Müller, Eclipse Foundation<br />
# Philipp Graf, FZI Forschungszentrum Informatik an der Universität Karlsruhe<br />
# Juan Domingo Florencio Duarte, Mercedes-Benz technology, electronics solutions<br />
# Dr. Tilmann Bubeck, reinform AG<br />
# Christian Rassek, Valyue Consulting GmbH<br />
# Maximilian Bock, Heidelberg Postpress Deutschland GmbH<br />
# Dr. Frank Gerhardt, Gerhardt Informatics Kft.<br />
# Stephan Hostie, SynSpace AG<br />
# Bernard Haible, ETAS GmbH<br />
# Marc Schanne, ITK Engineering AG<br />
# Artur Lojewski, babka software<br />
# Markus Grimm, Softwarearchitekt<br />
# Karl Schleier, TRW Automotive<br />
# Christoph Pöhlmann, TRW Automotive<br />
# Andreas Baier, Heidelberg Postpress Deutschland GmbH<br />
# Heiko Baur, Robert Bosch GmbH Plochingen <br />
# Peter Haeusler, Robert Bosch GmbH Plochingen <br />
# Eberhard Kümmel, Robert Bosch GmbH Plochingen <br />
# Volker Mader, Robert Bosch GmbH Plochingen <br />
# Hans Sperber, Robert Bosch GmbH Plochingen <br />
# Klaus-Dieter Niemann, Heidelberg Postpress Deutschland GmbH<br />
# Christian Knüchel, BMW Car IT GmbH<br />
# Eliane Fourgeau, Geensys <br />
# Kurt Ebert, itemis AG<br />
# Lothar Wendehals, itemis AG<br />
# Gerd Zanker, Bosch Thermotechnik GmbH<br />
# Georg Grütter, Robert Bosch GmbH<br />
# Harald Kästel-Baumgartner, Bosch Rexroth <br />
# Markus Völter, itemis AG<br />
# Andreas Graf, itemis AG<br />
# Miriam Brückner, itemis AG<br />
# Markus Zelleröhr, Verigy Germany GmbH<br />
# Hans-Jürgen Kugler, KUGLER MAAG CIE <br />
# Alexander Rieger, Innovations Software Technology GmbH<br />
# Markus Schärtel, Innovations Software Technology GmbH<br />
# Michael Gantert, Innovations Software Technology GmbH<br />
# Michael Städtler, Innovations Software Technology GmbH<br />
# Benjamin Fiebig, Innovations Software Technology GmbH<br />
# Oliver Feifel, Innovations Software Technology GmbH<br />
# Dr. Dimitar Valtchev, ProSyst Software GmbH<br />
# Dr.-Ing. Klaus-Rüdiger Hase, Deutsche Bahn AG<br />
# Janet Campbell, Eclipse Foundation<br />
# Jochen Krause, EclipseSource<br />
# Benjamin Felix, Geensys<br />
# Gaetan Morice, Anyware Technologies<br />
# Nicolas Setton, Adacore<br />
# James Branigan, Band XI International<br />
# Brett Hackleman, Band XI International<br />
# A R Imran, Robert Bosch GmbH<br />
# Harris Brakmic, Deutsche Telekom AG<br />
# Michael Burgbacher, phion AG<br />
# Martin Grundmann, Nokia Siemens Networks GmbH & Co. KG<br />
# Ingo Dohmann, I. Dohmann GmbH<br />
# Kay Dohmann, I. Dohmann GmbH<br />
# Ulrich Scheere, ICT Software Engineering Südwest GmbH<br />
# Rainer Goergens, Brunel GmbH<br />
# Dr. Manuel Galvez-Estrada, debitel AG<br />
# Matthias Albert, SEW-EURODRIVE GmbH & Co<br />
# Gabriel Reschka, BFFT Gesellschaft für Fahrzeugtechnik mbH<br />
# Matthias Zacharias, BMK electronic solutions GmbH<br />
# Tobias Weichbrodt, mm-lab GmbH<br />
# Markus Kaufhold, mm-lab GmbH<br />
# Uwe Asbach, ICT Software Engineering Südwest GmbH<br />
# Johan Strömhage, Purple Scout AB<br />
# Emil Erlandsson, Purple Scout AB<br />
# Bernhard Merkle, SICK AG<br />
# Jesudoss Daniel, Amdocs <br />
# Stephan Herrig, DAMBACH-Werke GmbH<br />
# David Pochet, Wavecom<br />
# Christoph Czernohous, IBM Deutschland Research & Development GmbH<br />
# Harald Mackamul, Robert Bosch GmbH<br />
# Dr. Stefan Jungmayr, Robert Bosch GmbH<br />
# Vitali Kuhn, DAMBACH-Werke GmbH<br />
# Dr. Uwe Werner, iocon<br />
# Frank Schumacher, Hochschule Pforzheim<br />
# Markus Holzer, Hochschule Pforzheim <br />
# Joachim Storz, Hochschule Pforzheim<br />
# Burkhard Weber, SICK AG<br />
# Sebastian Bollinger, Eberspächer Controls GmbH & Co. KG<br />
# Benjamin Lilienthal, Skeye Germany<br />
# Jürgen Hertweck, Hertweck IT-Consulting<br />
# Gunthilde Sohn, instinctools GmbH<br />
# Alexey Spas, instinctools GmbH<br />
# Alexander Pranko, instinctools GmbH<br />
# Dr. Stefan Zegenhagen, emlix GmbH<br />
# Daniel Stieger, Bachmann electronic GmbH <br />
# Wolfgang Messner, Bachmann electronic GmbH <br />
# Dragen Stevic, Bachmann electronic GmbH <br />
# Emmanuel Vertongen, IS2T<br />
# Timo O. Peichl, Alpine GmbH <br />
# Frank Adaschak, User Interface Design GmbH <br />
# Bernhard Boceck, Tesat-Spacecom GmbH & Co.KG<br />
# Stefan Löffler, Dambach-Werke GmbH<br />
# Dave Thomas, Bedarra Research Labs<br />
# Martin Figel, Daimler FleetBoard<br />
# Ravindra Nath, KUGLER MAAG CIE ASIA <br />
# Hajime Mitsubori, Panasonic Japan<br />
# Chen Tat Sze, Continental Singapore <br />
# Clemens Saur, KUGLER MAAG CIE ASIA <br />
# Dr. Alexander Fuchs, KF2Strategy GmbH<br />
# Knut Schwarz, Lemförder Electronic GmbH <br />
# Jürgen Hartung, Kölsch & Altmann Software & Management Consulting GmbH<br />
# John Cunningham, Band XI International<br />
# Peter Straubinger, Bizerba GmbH & Co. KG<br />
# Bernhard Gebert, Siemens AG <br />
<br />
<br />
Reference: [http://commons.wikimedia.org/wiki/File:Multi_Mega_mobo.jpg Sega Board] and [http://www.eclipse.org/artwork/ Eclipse Logo]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=EclipseEmbeddedDayStgt&diff=204541EclipseEmbeddedDayStgt2010-06-07T04:18:48Z<p>Michael.keppler.gmx.de: EclipseEmbeddedDayStgt moved to Eclipse Embedded Day Stuttgart 2009: search doesn't work for such titles</p>
<hr />
<div>#REDIRECT [[Eclipse Embedded Day Stuttgart 2009]]</div>Michael.keppler.gmx.dehttps://wiki.eclipse.org/index.php?title=Stuttgart_DemoCamp&diff=66755Stuttgart DemoCamp2007-12-06T13:33:10Z<p>Michael.keppler.gmx.de: /* Who Is Attending */</p>
<hr />
<div>[[Image:eclipse-camp.gif]] [[Eclipse_DemoCamp|What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
Café Stella<br>Hauptstätter Strasse 57<br><br />
70178 Stuttgart<br><br />
2nd floor<br><br />
http://www.cafe-stella.de/<br />
<br />
=== Date and Time ===<br />
<br />
December 7th, 7pm<br />
<br />
=== Organizer ===<br />
Joern Weigle, [http://www.weiglewilczek.com WeigleWilczek]<br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at a DemoCamp, please feel free to add your name and topic to the list. Each presentation will be about 15 minutes and we will have some time after each presentation for discussion.<br />
<br />
* WeigleWilczek will present the [http://rcml.net/ Rich Client Markup Language (RCML)] and show first use cases<br />
* Innoopract will present [http://www.innoopract.com/de/produkte/rich-ajax-plattform-rap.html RAP] and talk about the technology they used<br />
* [http://www.mind8.com Mind8] will present its RCP based product Mind8.Studio<br />
* GUI-Tests für RCP-Applikationen, Dr. Frank Gerhardt ([http://www.gerhardtinformatics.com www.gerhardtinformatics.com]), see article in [http://it-republik.de/jaxenter/eclipse-magazin-ausgaben/Professionell-testen-000229.html EclipseMagazin 4.2007]<br />
* Markus Kopf, [http://www.itemis.de itemis GmbH]: Little demo of the collaboration platform Jazz ([http://jazz.net/pub/index.jsp Jazz.net])<br />
<br />
=== Who Is Attending ===<br />
If you plan on attending please add your name to the list below. We'd like to see as many people show up as possible.<br />
* Joern Weigle, WeigleWilczek<br />
* Ilya Shinkarenko (50%), WeigleWilczek<br />
* Stephan Wilczek, Weigle Wilczek<br />
* Alexander Thurow, Weigle Wilczek<br />
* Daniela Blank, Weigle Wilczek<br />
* Wolfgang Werner (70%), [http://www.heiler.com Heiler Software AG]<br />
* Thomas Hartmann, (50%) [http://www.logicacmg.com/de Logica CMG]<br />
* Sascha Kaupp (70%), [http://www.datamaid.de Datamaid GmbH]<br />
* Silke Pfleiderer, Landeshauptstadt Stuttgart (maybe +2 Persons)<br />
* Martin Dilger (50%)<br />
* Mark Wedekind, Unilog Avinci a Logica CMG Company(60%) [http://www.logicacmg.com/de Logica CMG]<br />
* Marco Litto, Mind8 GmbH, Stuttgart<br />
* Tom Seidel (50%), [http://www.spiritlink.de Spirit Link GmbH], Erlangen<br />
* Mischa Höchsmann, [http://www.itemis.de itemis]<br />
* Markus Kopf, [http://www.itemis.de itemis]<br />
* Christian Dietrich, [http://www.itemis.de itemis]<br />
* Andreas Seelig, [http://www.bosch.com Robert Bosch GmbH]<br />
* Francois Bana, [http://www.t-systems.com T-Systems]<br />
* Stephan Kübler, [http://www.t-systems.com T-Systems]<br />
* Georg Cellary, [http://www.t-systems.com T-Systems]<br />
* Michael Schmidt, [http://www.object-it.de STZ object IT]<br />
* Michael Keppler, [http://www.etas.com ETAS GmbH] (maybe +1 person)</div>Michael.keppler.gmx.de