Generated from commit: https://github.com/eclipse/xtext/commit/6948f83a328c495a36ee81c261a7382186555aac
diff --git a/community.html b/community.html
index 9c66c85..dc54aa1 100644
--- a/community.html
+++ b/community.html
@@ -1225,14 +1225,6 @@
 					</tr>
 
 					<tr>
-						<td><a href="https://github.com/Yakindu/solidity-ide">YAKINDU Solidity IDE</a></td>
-						<td>The free to use, open source YAKINDU Solidity IDE provides an Xtext-based integrated development environment for Ethereum / Solidity-based smart contracts. It can be installed in different environments, such as Atom, Eclipse, Theia and VSCode. <a href="https://solidity-ide.itemis.de/">Online editor</a> and <a href="https://yakindu.github.io/solidity-ide/">documentation</a>.</td>
-						<td>EPL 1.0</td>
-						<td>Tool</td>
-						<td>Alexander Nyssen, Andreas M&uuml;lder, Florian Antony, et al. </td>
-					</tr>
-
-					<tr>
 						<td><a href="http://www.yakindu.org">Yakindu Statechart Tools</a></td>
 						<td>
 							YAKINDU Statechart Tools (SCT) provides an integrated modeling
diff --git a/documentation/103_domainmodelnextsteps.html b/documentation/103_domainmodelnextsteps.html
index b85ff1f..c9db239 100644
--- a/documentation/103_domainmodelnextsteps.html
+++ b/documentation/103_domainmodelnextsteps.html
@@ -196,7 +196,7 @@
 
 <ol>
   <li>
-    <p>First of all, you will have to filter the contents of the resource down to the defined entities. Therefore we need to iterate a resource with all its deeply nested elements. This can be achieved with the method <code>getAllContents()</code>. To use the resulting <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/TreeIterator.java">TreeIterator</a> in a <code>for</code> loop, we use the extension method <code>toIterable()</code> from the built-in library class <a href="https://github.com/eclipse/xtext-lib/blob/master/org.eclipse.xtext.xbase.lib/src/org/eclipse/xtext/xbase/lib/IteratorExtensions.java">IteratorExtensions</a>.</p>
+    <p>First of all, you will have to filter the contents of the resource down to the defined entities. Therefore we need to iterate a resource with all its deeply nested elements. This can be achieved with the method <code>getAllContents()</code>. To use the resulting <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/TreeIterator.java">TreeIterator</a> in a <code>for</code> loop, we use the extension method <code>toIterable()</code> from the built-in library class <a href="https://github.com/eclipse/xtext-lib/blob/master/org.eclipse.xtext.xbase.lib/src/org/eclipse/xtext/xbase/lib/IteratorExtensions.java">IteratorExtensions</a>.</p>
 
     <pre><code class="language-xtend">class DomainmodelGenerator extends AbstractGenerator {
 
diff --git a/documentation/104_jvmdomainmodel.html b/documentation/104_jvmdomainmodel.html
index 8250855..34e4b0c 100644
--- a/documentation/104_jvmdomainmodel.html
+++ b/documentation/104_jvmdomainmodel.html
@@ -486,7 +486,7 @@
     <pre><code class="language-xtend">documentation = element.documentation
 </code></pre>
 
-    <p>Here we assign some JavaDoc to the newly created element. The assignment is translated to an invocation of the method <em><a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.xbase/src/org/eclipse/xtext/xbase/jvmmodel/JvmTypesBuilder.java">JvmTypesBuilder</a>.setDocumentation(<a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.common.types/emf-gen/org/eclipse/xtext/common/types/JvmIdentifiableElement.java">JvmIdentifiableElement</a>, String)</em>, and <code>element.documentation</code> is in fact calling the extension method <em><a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.xbase/src/org/eclipse/xtext/xbase/jvmmodel/JvmTypesBuilder.java">JvmTypesBuilder</a>.getDocumentation(<a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>)</em>. Such extension methods are explained in detail in the <a href="https://www.eclipse.org/xtend/documentation/202_xtend_classes_members.html#extension-methods">Xtend documentation</a>.</p>
+    <p>Here we assign some JavaDoc to the newly created element. The assignment is translated to an invocation of the method <em><a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.xbase/src/org/eclipse/xtext/xbase/jvmmodel/JvmTypesBuilder.java">JvmTypesBuilder</a>.setDocumentation(<a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.common.types/emf-gen/org/eclipse/xtext/common/types/JvmIdentifiableElement.java">JvmIdentifiableElement</a>, String)</em>, and <code>element.documentation</code> is in fact calling the extension method <em><a href="https://github.com/eclipse/xtext-extras/blob/master/org.eclipse.xtext.xbase/src/org/eclipse/xtext/xbase/jvmmodel/JvmTypesBuilder.java">JvmTypesBuilder</a>.getDocumentation(<a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>)</em>. Such extension methods are explained in detail in the <a href="https://www.eclipse.org/xtend/documentation/202_xtend_classes_members.html#extension-methods">Xtend documentation</a>.</p>
   </li>
   <li>
     <pre><code class="language-xtend">if (element.superType !== null)
diff --git a/documentation/301_grammarlanguage.html b/documentation/301_grammarlanguage.html
index 24e88aa..9ffff87 100644
--- a/documentation/301_grammarlanguage.html
+++ b/documentation/301_grammarlanguage.html
@@ -200,7 +200,7 @@
 <pre><code class="language-xtext">generate domainmodel "http://www.example.org/domainmodel/Domainmodel"
 </code></pre>
 
-<p>That statement could actually be read as: generate an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a> with the <em>name</em> <code>domainmodel</code> and the <em>nsURI</em> <code>"http://www.example.org/domainmodel/Domainmodel"</code>. Xtext will then add <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClasses</a> with <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttributes</a> and <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReferences</a> for the different parser rules in your grammar, as described in <a href="301_grammarlanguage.html#metamodel-inference">Ecore model inference</a>.</p>
+<p>That statement could actually be read as: generate an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a> with the <em>name</em> <code>domainmodel</code> and the <em>nsURI</em> <code>"http://www.example.org/domainmodel/Domainmodel"</code>. Xtext will then add <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClasses</a> with <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttributes</a> and <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReferences</a> for the different parser rules in your grammar, as described in <a href="301_grammarlanguage.html#metamodel-inference">Ecore model inference</a>.</p>
 
 <h4 id="epackage-import">EPackage Import</h4>
 
@@ -209,7 +209,7 @@
 <pre><code class="language-xtext">import "http://www.xtext.org/example/Domainmodel"
 </code></pre>
 
-<p>A <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a> (Uniform Resource Identifier) provides a simple and extensible means for identifying an abstract or physical resource. It is also possible to import EPackages using resource URIs, but it is strongly recommended to use the namespace URI instead because it is independent from the concrete location in the file system, much more portable across different machines, easier to configure in the workflow, and works better with language mixins. The import via platform URIs or file URIs can be considered deprecated and is only supported for backwards compatibility.</p>
+<p>A <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a> (Uniform Resource Identifier) provides a simple and extensible means for identifying an abstract or physical resource. It is also possible to import EPackages using resource URIs, but it is strongly recommended to use the namespace URI instead because it is independent from the concrete location in the file system, much more portable across different machines, easier to configure in the workflow, and works better with language mixins. The import via platform URIs or file URIs can be considered deprecated and is only supported for backwards compatibility.</p>
 
 <p>Using package imports usually requires some <a href="302_configuration.html#importing-metamodels">adaptations in the generator workflow</a>.</p>
 
@@ -223,7 +223,7 @@
 
 <p>When referring to a type somewhere in the grammar you need to qualify the reference using that alias (e.g. <code>another::SomeType</code>). Cases where such type references occur are explained below.</p>
 
-<p>It is also supported to put multiple EPackage imports into one alias. This is no problem as long as there are not any two <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifiers</a> with the same name. In that case none of them can be referenced. It is even possible to <code>import</code> multiple and <code>generate</code> one Ecore model and declare all of them with the same alias. If you do so, for a reference to an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifier</a> first the imported <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackages</a> are scanned before it is assumed that a type needs to be generated into the inferred package.</p>
+<p>It is also supported to put multiple EPackage imports into one alias. This is no problem as long as there are not any two <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifiers</a> with the same name. In that case none of them can be referenced. It is even possible to <code>import</code> multiple and <code>generate</code> one Ecore model and declare all of them with the same alias. If you do so, for a reference to an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifier</a> first the imported <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackages</a> are scanned before it is assumed that a type needs to be generated into the inferred package.</p>
 
 <p>Note that using the same alias for multiple EPackages is not recommended, because it might cause problems that are hard to track down. For instance, a reference to <code>classA</code> could mistakenly be linked to a newly created EClass instead of an existing EClass <code>ClassA</code> because the latter is written with a capital letter.</p>
 
@@ -263,7 +263,7 @@
 
 <h4 id="return-types">Return Types</h4>
 
-<p>Each terminal rule returns an atomic value (an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>). By default, it’s assumed that an instance of <code>ecore::EString</code> should be returned. However, if you want to provide a different type you can specify it. For instance, the rule <em>INT</em> is defined as:</p>
+<p>Each terminal rule returns an atomic value (an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>). By default, it’s assumed that an instance of <code>ecore::EString</code> should be returned. However, if you want to provide a different type you can specify it. For instance, the rule <em>INT</em> is defined as:</p>
 
 <pre><code class="language-xtext">import "http://www.eclipse.org/emf/2002/Ecore" as ecore
 //...
@@ -385,7 +385,7 @@
 
 <h3 id="parser-rules">Parser Rules</h3>
 
-<p>The parser is fed with a sequence of terminals and walks through the so-called <em>parser rules</em>. Hence a parser rule – contrary to a terminal rule – does not produce a single atomic terminal token, but a tree of non-terminal and terminal tokens. They lead to a so-called <em>parse tree</em> (in Xtext it is also referred as <em>node model</em>). Furthermore, parser rules are handled as kind of a building plan for the creation of the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> that form the semantic model (the linked <em>abstract syntax tree</em> or AST). Due to this fact, parser rules are also called production or EObject rules. Different constructs like actions and assignments are used to derive types and initialize the semantic objects accordingly.</p>
+<p>The parser is fed with a sequence of terminals and walks through the so-called <em>parser rules</em>. Hence a parser rule – contrary to a terminal rule – does not produce a single atomic terminal token, but a tree of non-terminal and terminal tokens. They lead to a so-called <em>parse tree</em> (in Xtext it is also referred as <em>node model</em>). Furthermore, parser rules are handled as kind of a building plan for the creation of the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> that form the semantic model (the linked <em>abstract syntax tree</em> or AST). Due to this fact, parser rules are also called production or EObject rules. Different constructs like actions and assignments are used to derive types and initialize the semantic objects accordingly.</p>
 
 <h4 id="extended-backus-naur-form-expressions-1">Extended Backus-Naur Form Expressions</h4>
 
@@ -404,7 +404,7 @@
 
 <h5 id="assignments">Assignments</h5>
 
-<p>Assignments are used to assign the consumed information to a feature of the currently produced object. The type of the current object, its <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>, is specified by the return type of the parser rule. If it is not explicitly stated it is implied that the type’s name equals the rule’s name. The type of the assigned feature is inferred from the right hand side of the assignment.</p>
+<p>Assignments are used to assign the consumed information to a feature of the currently produced object. The type of the current object, its <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>, is specified by the return type of the parser rule. If it is not explicitly stated it is implied that the type’s name equals the rule’s name. The type of the assigned feature is inferred from the right hand side of the assignment.</p>
 
 <p>Example:</p>
 
@@ -440,7 +440,7 @@
     (many ?= 'many')? name = ID ':' type = [Type];
 </code></pre>
 
-<p>It is important to understand that the text between the square brackets does not refer to another rule, but to an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> – which is a type and not a parser rule. This can be sometimes confusing because one usually uses the same name for the rules and for the returned types.</p>
+<p>It is important to understand that the text between the square brackets does not refer to another rule, but to an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> – which is a type and not a parser rule. This can be sometimes confusing because one usually uses the same name for the rules and for the returned types.</p>
 
 <p>Looking at the syntax definition for cross-references, there is an optional part starting with a vertical bar (pipe) followed by <em>CrossReferenceableTerminal</em>. This is the part describing the concrete text from which the cross-reference should be established. If the terminal is omitted, it is expected to be the rule with the name <em>ID</em> – if one can be found. The terminal is mandatory for languages that do not define a rule with the name <em>ID</em>.</p>
 
@@ -491,7 +491,7 @@
 
 <p>The object to be returned by a parser rule is usually created lazily on the first assignment. Its type is determined from the specified return type of the rule, which may have been inferred from the rule’s name if no explicit return type is specified.</p>
 
-<p>With Actions however, the creation of returned <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> can be made explicit. Xtext supports two kinds of Actions:</p>
+<p>With Actions however, the creation of returned <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> can be made explicit. Xtext supports two kinds of Actions:</p>
 
 <ol>
   <li><em>Simple</em> Actions</li>
@@ -517,13 +517,13 @@
     "B" {TypeB} name=ID; 
 </code></pre>
 
-<p>Generally speaking, the instance is created as soon as the parser hits the first assignment. However, actions allow to explicitly instantiate any <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>. The notation <code>{TypeB}</code> will create an instance of <em>TypeB</em> and assign it to the result of the parser rule. This allows to define parser rules without any assignment and to create objects without the need to introduce unnecessary delegate rules.</p>
+<p>Generally speaking, the instance is created as soon as the parser hits the first assignment. However, actions allow to explicitly instantiate any <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>. The notation <code>{TypeB}</code> will create an instance of <em>TypeB</em> and assign it to the result of the parser rule. This allows to define parser rules without any assignment and to create objects without the need to introduce unnecessary delegate rules.</p>
 
 <p>Note: If a parser rule does not instantiate any object because it does not contain an Action and no mandatory Assignment, you’ll likely end up with unexpected situations for valid input files. Xtext detects this situation and will raise a warning (with a corresponding quickfix) for the parser rules in question.</p>
 
 <h5 id="unassigned-rule-calls">Unassigned Rule Calls</h5>
 
-<p>We previously explained that the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> to be returned is created lazily when the first assignment occurs or as soon as a simple action is evaluated. There is another concept to find the EObject to be returned, called <em>unassigned rule call</em>. Unassigned rule calls, as the name suggests it, are rule calls to other parser rules which are not used within an assignment. The return value of the called rule becomes the return value of the calling parser rule if it is not assigned to a feature.</p>
+<p>We previously explained that the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> to be returned is created lazily when the first assignment occurs or as soon as a simple action is evaluated. There is another concept to find the EObject to be returned, called <em>unassigned rule call</em>. Unassigned rule calls, as the name suggests it, are rule calls to other parser rules which are not used within an assignment. The return value of the called rule becomes the return value of the calling parser rule if it is not assigned to a feature.</p>
 
 <p>With unassigned rule calls one can, for instance, create rules which just dispatch to other rules:</p>
 
@@ -597,7 +597,7 @@
     {IntLiteral} value=INT;
 </code></pre>
 
-<p>In the example above <code>{Operation.left=current}</code> is a so-called <em>tree rewrite action</em>, which creates a new instance of the stated <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> <em>Operation</em> and assigns the element currently to-be-returned (the <code>current</code> variable) to a feature of the newly created object. The example uses the feature <em>left</em> of the <em>Operation</em> instance to store the previously returned <em>Expression</em>. In Java these semantics could be expressed as:</p>
+<p>In the example above <code>{Operation.left=current}</code> is a so-called <em>tree rewrite action</em>, which creates a new instance of the stated <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> <em>Operation</em> and assigns the element currently to-be-returned (the <code>current</code> variable) to a feature of the newly created object. The example uses the feature <em>left</em> of the <em>Operation</em> instance to store the previously returned <em>Expression</em>. In Java these semantics could be expressed as:</p>
 
 <pre><code class="language-java">Operation temp = new Operation();
 temp.setLeft(current);
@@ -674,7 +674,7 @@
 
 <h3 id="datatype-rules">Data Type Rules</h3>
 
-<p>Data type rules create instances of <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a> instead of <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. They are quite similar to terminal rules, but they are actually parser rules and are therefore</p>
+<p>Data type rules create instances of <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a> instead of <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. They are quite similar to terminal rules, but they are actually parser rules and are therefore</p>
 
 <ol>
   <li>context sensitive and</li>
@@ -705,7 +705,7 @@
 
 <p>Enum rules return enumeration literals from strings. They can be seen as a shortcut for data type rules with specific value converters. The main advantage of enum rules is their simplicity, type safety and therefore nice validation. Furthermore it is possible to infer enums and their respective literals during the Ecore model transformation.</p>
 
-<p>If you want to define a <code>ChangeKind</code> from <a href="https://github.com/eclipse/emf/blob/master/plugins/org.eclipse.emf.ecore.change/model/Change.ecore">org.eclipse.emf.ecore.change/model/Change.ecore</a> with <em>ADD</em>, <em>MOVE</em> and <em>REMOVE</em> you could write:</p>
+<p>If you want to define a <code>ChangeKind</code> from <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore.change/model/Change.ecore">org.eclipse.emf.ecore.change/model/Change.ecore</a> with <em>ADD</em>, <em>MOVE</em> and <em>REMOVE</em> you could write:</p>
 
 <pre><code class="language-xtext">enum ChangeKind:
     ADD | MOVE | REMOVE;
@@ -754,23 +754,23 @@
 <p>Xtext creates</p>
 
 <ul>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>
     <ul>
       <li>for each <code>generate</code> declaration. The <em>name</em> of the EPackage is set to the first parameter of such a declaration, its <em>nsURI</em> to the second parameter. An optional alias as the third parameter allows to distinguish the generated EPackages later. Only one generated package declaration per alias is allowed.</li>
     </ul>
   </li>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>
     <ul>
       <li>for each return type of a parser rule. If a parser rule does not define a return type, an implicit one with the same name as the rule itself is assumed. You can specify multiple rules that return the same type, but only one EClass is generated for each type name.</li>
       <li>for each type defined in an action or a cross-reference.</li>
     </ul>
   </li>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnum.java">EEnum</a>
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnum.java">EEnum</a>
     <ul>
       <li>for each return type of an enum rule.</li>
     </ul>
   </li>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>
     <ul>
       <li>for each return type of a terminal rule or a data type rule.</li>
     </ul>
@@ -795,13 +795,13 @@
 <p>While traversing the parser rules Xtext creates</p>
 
 <ul>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> in each current return type
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> in each current return type
     <ul>
       <li>of type <a href="http://docs.oracle.com/javase/8/docs/api/java/lang/Boolean.html">EBoolean</a> for each feature assignment using the <code>?=</code> operator. No further EReferences or EAttributes are generated from such an assignment.</li>
       <li>for each assignment with the <code>=</code> or <code>+=</code> operator calling a terminal rule or data type rule. Its type is the return type of the called rule.</li>
     </ul>
   </li>
-  <li>an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a> in each current return type
+  <li>an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a> in each current return type
     <ul>
       <li>for each assignment with the <code>=</code> or <code>+=</code> operator in a parser rule calling a parser rule. The type of the EReference is the return type of the called parser rule.</li>
       <li>for each assigned action. The type of the reference is the return type of the current rule containing the action.</li>
@@ -809,7 +809,7 @@
   </li>
 </ul>
 
-<p>Each <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> or <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a> takes its name from the assignment or action that caused it. Multiplicities are <code>0..1</code> for assignments with the <code>=</code> operator and <code>0..*</code> for assignments with the <code>+=</code> operator.</p>
+<p>Each <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> or <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a> takes its name from the assignment or action that caused it. Multiplicities are <code>0..1</code> for assignments with the <code>=</code> operator and <code>0..*</code> for assignments with the <code>+=</code> operator.</p>
 
 <p>Furthermore, each type that is added to the currently possible return types automatically extends the current return type of the parser rule. You can specify additional common super types by means of “artificial” parser rules that are never called, e.g.</p>
 
diff --git a/documentation/302_configuration.html b/documentation/302_configuration.html
index 423af20..97e4ce9 100644
--- a/documentation/302_configuration.html
+++ b/documentation/302_configuration.html
@@ -249,14 +249,14 @@
 }
 </code></pre>
 
-<p>Although arbitrary Java classes can be used, the standard root element for MWE2 files is <a href="https://github.com/eclipse/mwe/blob/v2.7.1/plugins/org.eclipse.emf.mwe2.runtime/src/org/eclipse/emf/mwe2/runtime/workflow/Workflow.java">Workflow</a>, which is part of the very slim runtime model shipped with MWE2. It accepts <em>beans</em> and <em>components</em>.</p>
+<p>Although arbitrary Java classes can be used, the standard root element for MWE2 files is <a href="https://github.com/eclipse/mwe/blob/v2.12.1/plugins/org.eclipse.emf.mwe2.runtime/src/org/eclipse/emf/mwe2/runtime/workflow/Workflow.java">Workflow</a>, which is part of the very slim runtime model shipped with MWE2. It accepts <em>beans</em> and <em>components</em>.</p>
 
 <ul>
   <li>
-    <p>The method Workflow.addBean(Object) provides a means to apply global side-effects, which unfortunately is required sometimes. For instance, <a href="https://github.com/eclipse/mwe/blob/v2.7.1/plugins/org.eclipse.emf.mwe.utils/src/org/eclipse/emf/mwe/utils/StandaloneSetup.java">StandaloneSetup</a> can be used to initialize global EMF metadata such as the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage.Registry</a>.</p>
+    <p>The method Workflow.addBean(Object) provides a means to apply global side-effects, which unfortunately is required sometimes. For instance, <a href="https://github.com/eclipse/mwe/blob/v2.12.1/plugins/org.eclipse.emf.mwe.utils/src/org/eclipse/emf/mwe/utils/StandaloneSetup.java">StandaloneSetup</a> can be used to initialize global EMF metadata such as the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage.Registry</a>.</p>
   </li>
   <li>
-    <p>The method Workflow.addComponent(..) accepts instances of <a href="https://github.com/eclipse/mwe/blob/v2.7.1/plugins/org.eclipse.emf.mwe2.runtime/src/org/eclipse/emf/mwe2/runtime/workflow/IWorkflowComponent.java">IWorkflowComponent</a>, which is the primary concept of the workflow model of MWE2. The language generator component itself is an instance of IWorkflowComponent and can therefore be used within MWE2 workflows.</p>
+    <p>The method Workflow.addComponent(..) accepts instances of <a href="https://github.com/eclipse/mwe/blob/v2.12.1/plugins/org.eclipse.emf.mwe2.runtime/src/org/eclipse/emf/mwe2/runtime/workflow/IWorkflowComponent.java">IWorkflowComponent</a>, which is the primary concept of the workflow model of MWE2. The language generator component itself is an instance of IWorkflowComponent and can therefore be used within MWE2 workflows.</p>
   </li>
 </ul>
 
@@ -380,7 +380,7 @@
 
 <ul>
   <li><code>name</code> – The name of the language exactly as specified in the first line of your grammar definition</li>
-  <li><code>grammarUri</code> – A <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a> pointing to the grammar definition file; if omitted, the grammar file is assumed to be in the Java source folder of the runtime project and to be named according to the language name.</li>
+  <li><code>grammarUri</code> – A <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a> pointing to the grammar definition file; if omitted, the grammar file is assumed to be in the Java source folder of the runtime project and to be named according to the language name.</li>
   <li><code>fileExtensions</code> – A comma-separated list of file extensions for the language</li>
   <li><code>referencedResources</code> – Additional resources to load (see <a href="#importing-metamodels">Importing Existing Metamodels</a>)</li>
 </ul>
@@ -454,7 +454,7 @@
 
 <p>If you are importing more than one metamodel, you can add more <code>referencedResource</code> declarations as required.</p>
 
-<p>In some occasions this simple way of referencing metamodels is not sufficient; you can then use the <a href="https://github.com/eclipse/mwe/blob/v2.7.1/plugins/org.eclipse.emf.mwe.utils/src/org/eclipse/emf/mwe/utils/StandaloneSetup.java">StandaloneSetup</a> as a Workflow bean for fine-tuning your EMF setup. Example:</p>
+<p>In some occasions this simple way of referencing metamodels is not sufficient; you can then use the <a href="https://github.com/eclipse/mwe/blob/v2.12.1/plugins/org.eclipse.emf.mwe.utils/src/org/eclipse/emf/mwe/utils/StandaloneSetup.java">StandaloneSetup</a> as a Workflow bean for fine-tuning your EMF setup. Example:</p>
 
 <pre><code class="language-mwe2">bean = StandaloneSetup {
     platformUri = "${rootPath}"
@@ -561,7 +561,7 @@
 }
 </code></pre>
 
-<p>The setup method returns an <a href="https://google.github.io/guice/api-docs/latest/javadoc/com/google/inject/Injector.html">Injector</a>, which can further be used to obtain a parser, etc. It also registers the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource.Factory</a> and generated <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackages</a> to the respective global registries provided by EMF. So basically after having run the setup you can start using EMF API to load and store models of your language.</p>
+<p>The setup method returns an <a href="https://google.github.io/guice/api-docs/latest/javadoc/com/google/inject/Injector.html">Injector</a>, which can further be used to obtain a parser, etc. It also registers the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource.Factory</a> and generated <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackages</a> to the respective global registries provided by EMF. So basically after having run the setup you can start using EMF API to load and store models of your language.</p>
 
 <p><strong>Caveat:</strong> The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/ISetup.java">ISetup</a> class is intended to be used for runtime and for unit testing, only. If you use it in an Equinox scenario, you will very likely break the running application because entries to the global registries will be overwritten.</p>
 
diff --git a/documentation/303_runtime_concepts.html b/documentation/303_runtime_concepts.html
index 59e0d0c..cf8543b 100644
--- a/documentation/303_runtime_concepts.html
+++ b/documentation/303_runtime_concepts.html
@@ -222,13 +222,13 @@
 
 <h4 id="syntactical-validation">Lexer/Parser: Syntactical Validation</h4>
 
-<p>The syntactical correctness of any textual input is validated automatically by the parser. The error messages are generated by the underlying parser technology. One can use the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/parser/antlr/ISyntaxErrorMessageProvider.java">ISyntaxErrorMessageProvider</a> API to customize these messages. Any syntax errors can be retrieved from the Resource using the common EMF API: the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getErrors()</code></a> and <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getWarnings()</code></a> method invocations.</p>
+<p>The syntactical correctness of any textual input is validated automatically by the parser. The error messages are generated by the underlying parser technology. One can use the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/parser/antlr/ISyntaxErrorMessageProvider.java">ISyntaxErrorMessageProvider</a> API to customize these messages. Any syntax errors can be retrieved from the Resource using the common EMF API: the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getErrors()</code></a> and <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getWarnings()</code></a> method invocations.</p>
 
 <h4 id="linking-validation">Linker: Cross-reference Validation</h4>
 
 <p>Any broken cross-references can be checked generically. As cross-reference resolution is done lazily (see <a href="#linking">linking</a>), any broken links are resolved lazily as well. If you want to validate whether all links are valid, you will have to navigate through the model so that all installed EMF proxies get resolved. This is done automatically in the editor.</p>
 
-<p>Similarly to syntax errors, any unresolvable cross-links will be reported and can be obtained through the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getErrors()</code></a> and <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getWarnings()</code></a> method invocations.</p>
+<p>Similarly to syntax errors, any unresolvable cross-links will be reported and can be obtained through the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getErrors()</code></a> and <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java"><code>Resource.getWarnings()</code></a> method invocations.</p>
 
 <h4 id="concrete-syntax-validation">Serializer: Concrete Syntax Validation</h4>
 
@@ -244,7 +244,7 @@
 
 <ol>
   <li>Types: only instances of <em>MyRule</em> and <em>MySubRule</em> are allowed for this rule. Subtypes are prohibited, since the parser never instantiates unknown subtypes.</li>
-  <li>Features: In case the <em>MyRule</em> and <em>MySubRule</em> have <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EStructuralFeature.java">EStructuralFeatures</a> besides <em>strVal</em> and <em>intVal</em>, only <em>strVal</em> and <em>intVal</em> may have <a href="#transient-values">non-transient values</a>.</li>
+  <li>Features: In case the <em>MyRule</em> and <em>MySubRule</em> have <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EStructuralFeature.java">EStructuralFeatures</a> besides <em>strVal</em> and <em>intVal</em>, only <em>strVal</em> and <em>intVal</em> may have <a href="#transient-values">non-transient values</a>.</li>
   <li>Quantities: The following condition must be true: <code>strVal.size() == intVal.size()</code>.</li>
   <li>Values: It must be possible to <a href="#value-converter">convert all values</a> to valid tokens for the used terminal rules <em>ID</em> and <em>INT</em>.</li>
 </ol>
@@ -259,7 +259,7 @@
   <li>Orders within list-features cannot be validated. e.g. <code>Rule: (foo+=R1 foo+=R2)*</code> implies that <em>foo</em> is expected to contain instances of <em>R1</em> and <em>R2</em> in an alternating order.</li>
 </ul>
 
-<p>To use concrete syntax validation you can let Guice inject an instance of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/validation/IConcreteSyntaxValidator.java">IConcreteSyntaxValidator</a> and use it directly. Furthermore, there is an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/validation/impl/ConcreteSyntaxEValidator.java">adapter</a> which allows to use the concrete syntax validator as an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EValidator.java">EValidator</a>. You can, for example, enable it in your runtime module, by adding:</p>
+<p>To use concrete syntax validation you can let Guice inject an instance of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/validation/IConcreteSyntaxValidator.java">IConcreteSyntaxValidator</a> and use it directly. Furthermore, there is an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/validation/impl/ConcreteSyntaxEValidator.java">adapter</a> which allows to use the concrete syntax validator as an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EValidator.java">EValidator</a>. You can, for example, enable it in your runtime module, by adding:</p>
 
 <pre><code class="language-java">@SingletonBinding(eager = true)
 public Class&lt;? extends ConcreteSyntaxEValidator&gt; bindConcreteSyntaxEValidator() {
@@ -329,7 +329,7 @@
 
 <p><code>ref Entity01</code></p>
 
-<p>the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/lazy/LazyLinker.java">LazyLinker</a> first creates an EMF proxy and assigns it to the corresponding <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. In EMF a proxy is described by a <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a>, which points to the real <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>. In the case of lazy linking the stored URI comprises of the context information given at parse time, which is the EObject containing the cross-reference, the actual EReference, the list index (in case it’s a multi-valued cross-reference) and the string which represented the cross-link in the concrete syntax. The latter usually corresponds to the name of the referenced EObject. In EMF a URI consists of information about the resource the EObject is contained in as well as a so called fragment part, which is used to find the EObject within that resource. When an EMF proxy is resolved, the current <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/ResourceSet.java">ResourceSet</a> is asked. The resource set uses the first part to obtain (i.e. load if it is not already loaded) the resource. Then the resource is asked to return the EObject based on the fragment in the URI. The actual cross-reference resolution is done by <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/lazy/LazyLinkingResource.java">LazyLinkingResource.getEObject(String)</a> which receives the fragment and delegates to the implementation of the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/ILinkingService.java">ILinkingService</a>. The default implementation in turn delegates to the <a href="#scoping">scoping API</a>.</p>
+<p>the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/lazy/LazyLinker.java">LazyLinker</a> first creates an EMF proxy and assigns it to the corresponding <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. In EMF a proxy is described by a <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a>, which points to the real <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>. In the case of lazy linking the stored URI comprises of the context information given at parse time, which is the EObject containing the cross-reference, the actual EReference, the list index (in case it’s a multi-valued cross-reference) and the string which represented the cross-link in the concrete syntax. The latter usually corresponds to the name of the referenced EObject. In EMF a URI consists of information about the resource the EObject is contained in as well as a so called fragment part, which is used to find the EObject within that resource. When an EMF proxy is resolved, the current <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/ResourceSet.java">ResourceSet</a> is asked. The resource set uses the first part to obtain (i.e. load if it is not already loaded) the resource. Then the resource is asked to return the EObject based on the fragment in the URI. The actual cross-reference resolution is done by <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/lazy/LazyLinkingResource.java">LazyLinkingResource.getEObject(String)</a> which receives the fragment and delegates to the implementation of the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/ILinkingService.java">ILinkingService</a>. The default implementation in turn delegates to the <a href="#scoping">scoping API</a>.</p>
 
 <p>A <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/linking/impl/DefaultLinkingService.java">simple implementation</a> of the linking service is shipped with Xtext and used for any grammar as default. Usually any necessary customization of the linking behavior can best be described using the <a href="#scoping">scoping API</a>.</p>
 
@@ -352,7 +352,7 @@
 
 <p>The grammar declares that for the reference <em>type</em> only instances of the type <em>Type</em> are allowed. However, this simple declaration doesn’t say anything about where to find the type. That is the duty of scopes.</p>
 
-<p>An <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScopeProvider.java">IScopeProvider</a> is responsible for providing an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScope.java">IScope</a> for a given context <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> and <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. The returned <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScope.java">IScope</a> should contain all target candidates for the given object and cross-reference.</p>
+<p>An <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScopeProvider.java">IScopeProvider</a> is responsible for providing an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScope.java">IScope</a> for a given context <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> and <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. The returned <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScope.java">IScope</a> should contain all target candidates for the given object and cross-reference.</p>
 
 <pre><code class="language-java">public interface IScopeProvider {
 
@@ -438,15 +438,15 @@
 
 <p>In order to make elements of one file referable from another file, you need to export them as part of a so called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a>.</p>
 
-<p>An IResourceDescription contains information about the resource itself, which primarily its <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a>, a list of exported <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> in the form of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a>s, as well as information about outgoing cross-references and qualified names it references. The cross-references contain only resolved references, while the list of imported qualified names also contains the names that couldn’t be resolved. This information is leveraged by the indexing infrastructure of Xtext in order to compute the transitive hull of dependent resources.</p>
+<p>An IResourceDescription contains information about the resource itself, which primarily its <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.common/src/org/eclipse/emf/common/util/URI.java">URI</a>, a list of exported <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> in the form of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a>s, as well as information about outgoing cross-references and qualified names it references. The cross-references contain only resolved references, while the list of imported qualified names also contains the names that couldn’t be resolved. This information is leveraged by the indexing infrastructure of Xtext in order to compute the transitive hull of dependent resources.</p>
 
-<p>For users, and especially in the context of scoping, the most important information is the list of exported EObjects. An IEObjectDescription stores the URI of the actual EObject, its <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/QualifiedName.java">QualifiedName</a>, as well as its <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. In addition one can export arbitrary information using the <em>user data</em> map. The following diagram gives an overview on the description classes and their relationships.</p>
+<p>For users, and especially in the context of scoping, the most important information is the list of exported EObjects. An IEObjectDescription stores the URI of the actual EObject, its <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/QualifiedName.java">QualifiedName</a>, as well as its <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. In addition one can export arbitrary information using the <em>user data</em> map. The following diagram gives an overview on the description classes and their relationships.</p>
 
 <p><img src="images/index_datamodel.png" alt="The data model of Xtext's index" /></p>
 
-<p>A language is configured with default implementations of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription.Manager</a> and <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/impl/DefaultResourceDescriptionStrategy.java">DefaultResourceDescriptionStrategy</a>, which are responsible to compute the list of exported <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescriptions</a>. The Manager iterates over the whole EMF model for each <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource</a> and asks the ResourceDescriptionStrategy to compute an IEObjectDescription for each EObject. The ResourceDescriptionStrategy applies the <code>getQualifiedName(EObject obj)</code> from <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/IQualifiedNameProvider.java">IQualifiedNameProvider</a> on the object, and if it has a qualified name an IEObjectDescription is created and passed back to the Manager which adds it to the list of exported objects. If an EObject doesn’t have a qualified name, the element is considered to be not referable from outside the resource and consequently not indexed. If you don’t like this behavior, you can implement and bind your own implementation of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IDefaultResourceDescriptionStrategy.java">IDefaultResourceDescriptionStrategy</a>.</p>
+<p>A language is configured with default implementations of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription.Manager</a> and <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/impl/DefaultResourceDescriptionStrategy.java">DefaultResourceDescriptionStrategy</a>, which are responsible to compute the list of exported <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescriptions</a>. The Manager iterates over the whole EMF model for each <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource</a> and asks the ResourceDescriptionStrategy to compute an IEObjectDescription for each EObject. The ResourceDescriptionStrategy applies the <code>getQualifiedName(EObject obj)</code> from <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/IQualifiedNameProvider.java">IQualifiedNameProvider</a> on the object, and if it has a qualified name an IEObjectDescription is created and passed back to the Manager which adds it to the list of exported objects. If an EObject doesn’t have a qualified name, the element is considered to be not referable from outside the resource and consequently not indexed. If you don’t like this behavior, you can implement and bind your own implementation of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IDefaultResourceDescriptionStrategy.java">IDefaultResourceDescriptionStrategy</a>.</p>
 
-<p>There are two different default implementations of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/IQualifiedNameProvider.java">IQualifiedNameProvider</a>. Both work by looking up an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> ‘<em>name</em>’. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/SimpleNameProvider.java">SimpleNameProvider</a> simply returns the plain value, while the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/DefaultDeclarativeQualifiedNameProvider.java">DefaultDeclarativeQualifiedNameProvider</a> concatenates the simple name with the qualified name of its parent exported EObject. This effectively simulates the qualified name computation of most namespace-based languages such as Java. It also allows to override the name computation declaratively: Just add methods named <code>qualifiedName</code> in a subclass and give each of them one argument with the type of element you wish to compute a name for.</p>
+<p>There are two different default implementations of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/IQualifiedNameProvider.java">IQualifiedNameProvider</a>. Both work by looking up an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> ‘<em>name</em>’. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/SimpleNameProvider.java">SimpleNameProvider</a> simply returns the plain value, while the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/DefaultDeclarativeQualifiedNameProvider.java">DefaultDeclarativeQualifiedNameProvider</a> concatenates the simple name with the qualified name of its parent exported EObject. This effectively simulates the qualified name computation of most namespace-based languages such as Java. It also allows to override the name computation declaratively: Just add methods named <code>qualifiedName</code> in a subclass and give each of them one argument with the type of element you wish to compute a name for.</p>
 
 <p>As already mentioned, the default implementation strategy exports every model element that the IQualifiedNameProvider can provide a name for. This is a good starting point, but when your models become bigger and you have a lot of them the index will become larger and larger. In most scenarios only a small part of your model should be visible from outside, hence only that small part needs to be in the index. In order to do this, bind a custom implementation of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IDefaultResourceDescriptionStrategy.java">IDefaultResourceDescriptionStrategy</a> and create index representations only for those elements that you want to reference from outside the resource they are contained in. From within the resource, references to those filtered elements are still possible as long as they have a name.</p>
 
@@ -479,7 +479,7 @@
 
 <p>To enable support for this kind of global scoping in Xtext, a <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/impl/DefaultGlobalScopeProvider.java">DefaultGlobalScopeProvider</a> has to be bound to the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IGlobalScopeProvider.java">IGlobalScopeProvider</a> interface. By default Xtext leverages the class path mechanism since it is well designed and already understood by most of our users. The available tooling provided by JDT and PDE to configure the class path adds even more value. However, it is just a default: you can reuse the infrastructure without using Java and be independent of the JDT.</p>
 
-<p>In order to know what is available in the “world”, a global scope provider which relies on external configuration needs to read that configuration in and be able to find all candidates for a certain <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. If you don’t want to force users to have a folder and file name structure reflecting the actual qualified names of the referenceable <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a>, you’ll have to load all resources up front and either keep holding them in memory or remember all information which is needed for the resolution of cross-references. In Xtext that information is provided by a so-called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a>.</p>
+<p>In order to know what is available in the “world”, a global scope provider which relies on external configuration needs to read that configuration in and be able to find all candidates for a certain <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EReference.java">EReference</a>. If you don’t want to force users to have a folder and file name structure reflecting the actual qualified names of the referenceable <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a>, you’ll have to load all resources up front and either keep holding them in memory or remember all information which is needed for the resolution of cross-references. In Xtext that information is provided by a so-called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a>.</p>
 
 <h5 id="containers">About the Index, Containers and Their Manager</h5>
 
@@ -487,7 +487,7 @@
 
 <p>The index is basically a flat list of instances of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a>. The index itself doesn’t know about visibility constraints due to class path restriction. Rather than that, they are defined by the referencing language by means of so called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IContainer.java">IContainers</a>: While Java might load a resource via <a href="http://docs.oracle.com/javase/8/docs/api/java/lang/ClassLoader.html">ClassLoader.loadResource()</a> (i.e. using the class path mechanism), another language could load the same resource using the file system paths.</p>
 
-<p>Consequently, the information which container a resource belongs to depends on the referencing context. Therefore an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceServiceProvider.java">IResourceServiceProvider</a> provides another interesting service, which is called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IContainer.java">IContainer.Manager</a>. For a given <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a>, the Manager provides you the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IContainer.java">IContainer</a> as well as a list of all IContainers which are visible from there. Note that the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescriptions.java">index</a> is globally shared between all languages while the Manager, which adds the semantics of containers, can be very different depending on the language. The following method lists all resources visible from a given <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource</a>:</p>
+<p>Consequently, the information which container a resource belongs to depends on the referencing context. Therefore an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceServiceProvider.java">IResourceServiceProvider</a> provides another interesting service, which is called <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IContainer.java">IContainer.Manager</a>. For a given <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a>, the Manager provides you the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IContainer.java">IContainer</a> as well as a list of all IContainers which are visible from there. Note that the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescriptions.java">index</a> is globally shared between all languages while the Manager, which adds the semantics of containers, can be very different depending on the language. The following method lists all resources visible from a given <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Resource</a>:</p>
 
 <pre><code class="language-xtend">@Inject IContainer.Manager manager
  
@@ -600,7 +600,7 @@
 
 <h4 id="importing-namespaces">Importing Namespaces</h4>
 
-<p>The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/impl/ImportedNamespaceAwareLocalScopeProvider.java">ImportedNamespaceAwareLocalScopeProvider</a> looks up <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttributes</a> with name <em>importedNamespace</em> and interprets them as import statements.</p>
+<p>The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/impl/ImportedNamespaceAwareLocalScopeProvider.java">ImportedNamespaceAwareLocalScopeProvider</a> looks up <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttributes</a> with name <em>importedNamespace</em> and interprets them as import statements.</p>
 
 <pre><code class="language-xtext">PackageDeclaration:
     'package' name=QualifiedName '{'
@@ -658,7 +658,7 @@
 }
 </code></pre>
 
-<p>If you use the common terminals grammar <code>org.eclipse.xtext.common.Terminals</code> you should extend the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/common/services/DefaultTerminalConverters.java">DefaultTerminalConverters</a> and override or add value converters by adding the respective methods. In addition to the explicitly defined converters in the default implementation, a delegating converter is registered for each available <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>. The delegating converter reuses the functionality of the corresponding EMF <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EFactory.java">EFactory</a>.</p>
+<p>If you use the common terminals grammar <code>org.eclipse.xtext.common.Terminals</code> you should extend the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/common/services/DefaultTerminalConverters.java">DefaultTerminalConverters</a> and override or add value converters by adding the respective methods. In addition to the explicitly defined converters in the default implementation, a delegating converter is registered for each available <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EDataType.java">EDataType</a>. The delegating converter reuses the functionality of the corresponding EMF <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EFactory.java">EFactory</a>.</p>
 
 <p>Many languages introduce a concept for qualified names, i.e. names composed of namespaces separated by a delimiter. Since this is such a common use case, Xtext provides an extensible converter implementation for qualified names. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/conversion/impl/QualifiedNameValueConverter.java">QualifiedNameValueConverter</a> handles comments and white spaces gracefully and is capable to use the appropriate value converter for each segment of a qualified name. This allows for individually quoted segments. The domainmodel example shows how to use it.</p>
 
diff --git a/documentation/305_xbase.html b/documentation/305_xbase.html
index 075b4a1..1432761 100644
--- a/documentation/305_xbase.html
+++ b/documentation/305_xbase.html
@@ -394,7 +394,7 @@
 <pre><code class="language-xtext">grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.xbase.Xbase
 </code></pre>
 
-<p>If you want to refer to <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifiers</a> from the Xbase model, you need to import Xbase first:</p>
+<p>If you want to refer to <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClassifier.java">EClassifiers</a> from the Xbase model, you need to import Xbase first:</p>
 
 <pre><code class="language-xtext">import "http://www.eclipse.org/xtext/xbase/Xbase" as xbase
 </code></pre>
diff --git a/documentation/308_emf_integration.html b/documentation/308_emf_integration.html
index a230ade..3a06ae3 100644
--- a/documentation/308_emf_integration.html
+++ b/documentation/308_emf_integration.html
@@ -177,7 +177,7 @@
 
 <p><img src="images/ast.png" alt="Sample AST" /></p>
 
-<p>The <em>AST</em> should contain the essence of your textual models. It abstracts over syntactical information. It is used by later processing steps, such as validation, compilation or interpretation. In EMF a model is made up of instances of <em>EObjects</em> which are connected. An <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> is an instance of an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. A set of <em>EClasses</em> can be contained in a so called <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>, which are both concepts of <em>Ecore</em>. In Xtext, meta-models are either inferred from the grammar or predefined by the user (see the section on <a href="301_grammarlanguage.html#package-declarations">EPackage declarations</a> for details). The next diagram shows the meta-model of our example:</p>
+<p>The <em>AST</em> should contain the essence of your textual models. It abstracts over syntactical information. It is used by later processing steps, such as validation, compilation or interpretation. In EMF a model is made up of instances of <em>EObjects</em> which are connected. An <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> is an instance of an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a>. A set of <em>EClasses</em> can be contained in a so called <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>, which are both concepts of <em>Ecore</em>. In Xtext, meta-models are either inferred from the grammar or predefined by the user (see the section on <a href="301_grammarlanguage.html#package-declarations">EPackage declarations</a> for details). The next diagram shows the meta-model of our example:</p>
 
 <p><img src="images/metamodel.png" alt="Sample meta model" /></p>
 
@@ -193,7 +193,7 @@
 
 <p>The superclass of EAttributes and EReferences is <em>EStructuralFeature</em> and allows to define a name and a cardinality by setting <em>lowerBound</em> and <em>upperBound</em>. Setting the latter to -1 means ‘unbounded’.</p>
 
-<p>The common super type of EDataType and EClass is <em>EClassifier</em>. An <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a> acts as a namespace and container of EClassifiers.</p>
+<p>The common super type of EDataType and EClass is <em>EClassifier</em>. An <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a> acts as a namespace and container of EClassifiers.</p>
 
 <p>We have summarized these most relevant concepts of Ecore in the following diagram:</p>
 
@@ -208,9 +208,9 @@
 <p>Among other things, the code generator will generate</p>
 
 <ul>
-  <li>A Java interface and a Java class for each EClassifier in your Ecore model. By default, all classes will implement the interface <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>, linking a lot of runtime functionality.</li>
+  <li>A Java interface and a Java class for each EClassifier in your Ecore model. By default, all classes will implement the interface <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a>, linking a lot of runtime functionality.</li>
   <li>A Java bean property for each EStructuralFeature (member variable, accessor methods).</li>
-  <li>A package interface and class, holding singleton objects for all elements of your Ecore model, allowing reflection. EPackages are also registered to the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">Registry</a> to be usable at runtime.</li>
+  <li>A package interface and class, holding singleton objects for all elements of your Ecore model, allowing reflection. EPackages are also registered to the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">Registry</a> to be usable at runtime.</li>
   <li>A factory interface and class for creating instances.</li>
   <li>An abstract switch class implementing a visitor pattern to avoid if-instanceof-cascades in your code.</li>
 </ul>
@@ -240,13 +240,13 @@
   <li>Implement an <a href="#fragment-provider">IFragmentProvider</a> to make the XtextResource return stable fragments for its contained elements, e.g. based on composite names rather than order of appearance.</li>
   <li>Implement an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/naming/IQualifiedNameProvider.java">IQualifiedNameProvider</a> and an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/scoping/IScopeProvider.java">IScopeProvider</a> (<a href="303_runtime_concepts.html#scoping">how-to</a>) to make the names of all linkable elements in cross-references unique.</li>
   <li>Provide an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/formatting/IFormatter.java">IFormatter</a> (<a href="303_runtime_concepts.html#formatting">how-to</a>) to improve the readability of the generated textual models.</li>
-  <li>Register an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/parser/antlr/IReferableElementsUnloader.java">IReferableElementsUnloader</a> to turn deleted/replaced model elements into EMF proxies. Design the rest of your application such that it does never keep references to <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> or to cope with proxies. That will improve the stability of your application drastically.</li>
-  <li>Xtext will register an EMF <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Factory</a>, so resources with the file extension you entered when generating the Xtext plug-ins will be automatically loaded in an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/XtextResource.java">XtextResource</a> when you use EMF’s <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/ResourceSet.java">ResourceSet</a> API to load it.</li>
+  <li>Register an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/parser/antlr/IReferableElementsUnloader.java">IReferableElementsUnloader</a> to turn deleted/replaced model elements into EMF proxies. Design the rest of your application such that it does never keep references to <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a> or to cope with proxies. That will improve the stability of your application drastically.</li>
+  <li>Xtext will register an EMF <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/Resource.java">Factory</a>, so resources with the file extension you entered when generating the Xtext plug-ins will be automatically loaded in an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/XtextResource.java">XtextResource</a> when you use EMF’s <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/resource/ResourceSet.java">ResourceSet</a> API to load it.</li>
 </ul>
 
 <h2 id="fragment-provider">Referencing From EMF</h2>
 
-<p>In some cases you may want to be able to reference an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> of an Xtext model from another EMF artifact that is not managed by Xtext. In those cases URIs are used, which are made up of a part identifying the resource and a second part that points to an object. Each <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> contained in a resource can be identified by a so called <em>fragment</em>.</p>
+<p>In some cases you may want to be able to reference an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> of an Xtext model from another EMF artifact that is not managed by Xtext. In those cases URIs are used, which are made up of a part identifying the resource and a second part that points to an object. Each <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> contained in a resource can be identified by a so called <em>fragment</em>.</p>
 
 <p>A fragment is a part of an EMF URI and needs to be unique per resource.</p>
 
@@ -254,9 +254,9 @@
 
 <p>With an XMI or other binary-like serialization it is also common and possible to use UUIDs. UUIDs are usually binary and technical, so you don’t want to deal with them in human readable representations.</p>
 
-<p>However with a textual concrete syntax we want to be able to compute fragments out of the human readable information. We don’t want to force people to use UUIDs (i.e. synthetic identifiers) or fragile, relative, generic paths in order to refer to <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a>.</p>
+<p>However with a textual concrete syntax we want to be able to compute fragments out of the human readable information. We don’t want to force people to use UUIDs (i.e. synthetic identifiers) or fragile, relative, generic paths in order to refer to <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObjects</a>.</p>
 
-<p>Therefore one can contribute an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IFragmentProvider.java">IFragmentProvider</a> per language. It has two methods: <code>getFragment(EObject, Fallback)</code> to calculate the fragment of an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> and <code>getEObject(Resource, String, Fallback)</code> to go the opposite direction. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IFragmentProvider.java">Fallback</a> interface allows to delegate to the default strategy - which usually uses the fragment paths described above.</p>
+<p>Therefore one can contribute an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IFragmentProvider.java">IFragmentProvider</a> per language. It has two methods: <code>getFragment(EObject, Fallback)</code> to calculate the fragment of an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java">EObject</a> and <code>getEObject(Resource, String, Fallback)</code> to go the opposite direction. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IFragmentProvider.java">Fallback</a> interface allows to delegate to the default strategy - which usually uses the fragment paths described above.</p>
 
 <p>The following snippet shows how to use qualified names as fragments:</p>
 
diff --git a/documentation/310_eclipse_support.html b/documentation/310_eclipse_support.html
index d8308ef..0e84b4b 100644
--- a/documentation/310_eclipse_support.html
+++ b/documentation/310_eclipse_support.html
@@ -195,7 +195,7 @@
 }
 </code></pre>
 
-<p>If your grammar uses an imported <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>, there may be an existing <em>edit</em>-plug-in generated by EMF that also provides label providers for model elements. To use this as a fallback, your label provider should call the constructor with the delegate parameter and use dependency injection for its initialization, e.g.</p>
+<p>If your grammar uses an imported <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EPackage.java">EPackage</a>, there may be an existing <em>edit</em>-plug-in generated by EMF that also provides label providers for model elements. To use this as a fallback, your label provider should call the constructor with the delegate parameter and use dependency injection for its initialization, e.g.</p>
 
 <pre><code class="language-java">public class MyLabelProvider {
   @Inject  
@@ -226,7 +226,7 @@
 }
 </code></pre>
 
-<p>What is especially nice about the default implementation is the actual reason for its class name: It provides very reasonable defaults. To compute the label for a certain model element, it will first look for an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> <em>name</em> and try to use this one. If it cannot find such a feature, it will try to use the first feature that can be used best as a label. At worst it will return the class name of the model element, which is kind of unlikely to happen.</p>
+<p>What is especially nice about the default implementation is the actual reason for its class name: It provides very reasonable defaults. To compute the label for a certain model element, it will first look for an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> <em>name</em> and try to use this one. If it cannot find such a feature, it will try to use the first feature that can be used best as a label. At worst it will return the class name of the model element, which is kind of unlikely to happen.</p>
 
 <p>You can also customize error handling by overriding the methods <code>handleTextError()</code> or <code>handleImageError()</code>.</p>
 
@@ -234,7 +234,7 @@
 
 <p>Xtext maintains an index of all model elements to allow quick searching and linking without loading the referenced resource (see the chapter on <a href="303_runtime_concepts.html#index-based">index-based scopes</a> for details). The elements from this index also appear in some UI contexts, e.g. in the <em>Find model elements</em> dialog or in the <em>Find references</em> view. For reasons of scalability, the UI should not automatically load resources, so we need another implementation of a label provider that works with the elements from the index, i.e. <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a>, <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a>, and <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IReferenceDescription.java">IReferenceDescription</a>.</p>
 
-<p>The default implementation of this service is the <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/label/DefaultDescriptionLabelProvider.java">DefaultDescriptionLabelProvider</a>. It employs the same polymorphic dispatch mechanism as the <a href="#default-eobject-label-provider">DefaultEObjectLabelProvider</a>. The default text of an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a> is its indexed name. The image is resolved by dispatching to <code>image(EClass)</code> with the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> of the described object. This is likely the only method you want to override. Instances of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a> will be represented with their path and the icon registered for your language’s editor.</p>
+<p>The default implementation of this service is the <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/label/DefaultDescriptionLabelProvider.java">DefaultDescriptionLabelProvider</a>. It employs the same polymorphic dispatch mechanism as the <a href="#default-eobject-label-provider">DefaultEObjectLabelProvider</a>. The default text of an <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IEObjectDescription.java">IEObjectDescription</a> is its indexed name. The image is resolved by dispatching to <code>image(EClass)</code> with the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> of the described object. This is likely the only method you want to override. Instances of <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/IResourceDescription.java">IResourceDescription</a> will be represented with their path and the icon registered for your language’s editor.</p>
 
 <p>To have a custom description label provider, make sure it is bound in your UI module:</p>
 
@@ -438,7 +438,7 @@
 
 <h3 id="enumeration-template-variable-resolver">Enumeration Template Variable Resolver</h3>
 
-<p>The <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/editor/templates/EnumTemplateVariableResolver.java">EnumTemplateVariableResolver</a> resolves a template variable to <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnumLiteral.java">EEnumLiterals</a> which are assignment-compatible to the enumeration type declared as the first parameter of the <em>Enum</em> template variable.</p>
+<p>The <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/editor/templates/EnumTemplateVariableResolver.java">EnumTemplateVariableResolver</a> resolves a template variable to <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnumLiteral.java">EEnumLiterals</a> which are assignment-compatible to the enumeration type declared as the first parameter of the <em>Enum</em> template variable.</p>
 
 <p>The syntax is as follows:</p>
 
@@ -458,7 +458,7 @@
 &lt;/template&gt;
 </code></pre>
 
-<p>yields the text <code>public entity Name {}</code> where the text <code>public</code> is the default value of the <code>Visibility</code>. The editor provides a drop down that is populated with the other literal values as defined in the <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnum.java">EEnum</a>.</p>
+<p>yields the text <code>public entity Name {}</code> where the text <code>public</code> is the default value of the <code>Visibility</code>. The editor provides a drop down that is populated with the other literal values as defined in the <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EEnum.java">EEnum</a>.</p>
 
 <h2 id="outline">Outline View</h2>
 
@@ -703,12 +703,12 @@
 <p>When navigating a hyperlink, Xtext will also select the text region corresponding to the referenced model element. Determining this text region is the responsibility of the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/ILocationInFileProvider.java">ILocationInFileProvider</a>. The <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/DefaultLocationInFileProvider.java">default implementation</a> implements a best effort strategy which can be summarized as:</p>
 
 <ol>
-  <li>If the model element’s <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">type</a> declares a feature <em>name</em> then return the region of the corresponding token(s). As a fallback also check for a feature <em>id</em>.</li>
+  <li>If the model element’s <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">type</a> declares a feature <em>name</em> then return the region of the corresponding token(s). As a fallback also check for a feature <em>id</em>.</li>
   <li>If the model element’s node model contains any top-level tokens corresponding to invocations of the rule <em>ID</em> in the grammar then return a region spanning all those tokens.</li>
   <li>As a last resort return the region corresponding to the first keyword token of the referenced model element.</li>
 </ol>
 
-<p>The location service offers different methods to obtain the region of interest for special use cases. You can either obtain the complete region for an object or only the identifying string which is usually the name of the instance (see <code>getSignificantTextRegion(EObject)</code>). You can also query for the text region of a specific <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EStructuralFeature.java">EStructuralFeature</a> by means of <code>getFullTextRegion(EObject, EStructuralFeature, int)</code>.</p>
+<p>The location service offers different methods to obtain the region of interest for special use cases. You can either obtain the complete region for an object or only the identifying string which is usually the name of the instance (see <code>getSignificantTextRegion(EObject)</code>). You can also query for the text region of a specific <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EStructuralFeature.java">EStructuralFeature</a> by means of <code>getFullTextRegion(EObject, EStructuralFeature, int)</code>.</p>
 
 <p>As the default strategy is a best effort it may not always result in the selection you want. If that’s the case you can <a href="302_configuration.html#guicemodules">override</a> the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/ILocationInFileProvider.java">ILocationInFileProvider</a> binding in the UI module as in the following example:</p>
 
@@ -897,7 +897,7 @@
 <p>The most likely component you want to customize is the <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/refactoring/IRenameStrategy.java">IRenameStrategy</a>. This component defines how the declaration of the target element is performed. It has two major responsibilities:</p>
 
 <ul>
-  <li>Apply and revert the declaration change on the semantic model (methods <code>applyDeclarationChange</code> and <code>revertDeclarationChange</code>). The default is to look for an <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> <code>name</code> on the target object and set its value using EMFs reflective API.</li>
+  <li>Apply and revert the declaration change on the semantic model (methods <code>applyDeclarationChange</code> and <code>revertDeclarationChange</code>). The default is to look for an <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EAttribute.java">EAttribute</a> <code>name</code> on the target object and set its value using EMFs reflective API.</li>
   <li>Create the LTK <a href="http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/Change.html">Change</a> objects of the declaration change. These changes will be aggregated, checked for overlaps, presented to you in the preview and finally executed if you apply the refactoring. The default is to use the <a href="https://github.com/eclipse/xtext-core/blob/master/org.eclipse.xtext/src/org/eclipse/xtext/resource/ILocationInFileProvider.java">ILocationInFileProvider</a> to locate the text range representing the name and create a <a href="http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/text/edits/ReplaceEdit.html">ReplaceEdit</a> for it.</li>
 </ul>
 
@@ -907,7 +907,7 @@
 
 <h3 id="rename-participants">Rename Participants</h3>
 
-<p>One refactoring can trigger another: When renaming a rule in an Xtext grammar, the returned <a href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> should be renamed, too. For these cases, you can register a <a href="http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/participants/RenameParticipant.html">RenameParticipant</a> by the common means of LTK. If the target of the participant is Xtext based, you can use a <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/refactoring/impl/AbstractProcessorBasedRenameParticipant.java">AbstractProcessorBasedRenameParticipant</a>.</p>
+<p>One refactoring can trigger another: When renaming a rule in an Xtext grammar, the returned <a href="https://git.eclipse.org/r/plugins/gitiles/emf/org.eclipse.emf/+/refs/tags/R2_20_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EClass.java">EClass</a> should be renamed, too. For these cases, you can register a <a href="http://help.eclipse.org/luna/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/ltk/core/refactoring/participants/RenameParticipant.html">RenameParticipant</a> by the common means of LTK. If the target of the participant is Xtext based, you can use a <a href="https://github.com/eclipse/xtext-eclipse/blob/master/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/refactoring/impl/AbstractProcessorBasedRenameParticipant.java">AbstractProcessorBasedRenameParticipant</a>.</p>
 
 <h2 id="projectwizard">Project Wizard</h2>
 
diff --git a/feed.xml b/feed.xml
index a8a2315..df3ad4a 100644
--- a/feed.xml
+++ b/feed.xml
@@ -6,8 +6,8 @@
 </description>
     <link>http://xtext.org/Xtext/</link>
     <atom:link href="http://xtext.org/Xtext/feed.xml" rel="self" type="application/rss+xml"/>
-    <pubDate>Wed, 04 Aug 2021 05:41:45 +0000</pubDate>
-    <lastBuildDate>Wed, 04 Aug 2021 05:41:45 +0000</lastBuildDate>
+    <pubDate>Mon, 27 Sep 2021 06:05:50 +0000</pubDate>
+    <lastBuildDate>Mon, 27 Sep 2021 06:05:50 +0000</lastBuildDate>
     <generator>Jekyll v2.5.3</generator>
     
       <item>