diff --git a/features/org.eclipse.rcp/rootfiles/readme/readme_eclipse.html b/features/org.eclipse.rcp/rootfiles/readme/readme_eclipse.html
index 2ad758d..0b30f8d 100644
--- a/features/org.eclipse.rcp/rootfiles/readme/readme_eclipse.html
+++ b/features/org.eclipse.rcp/rootfiles/readme/readme_eclipse.html
@@ -4,9 +4,9 @@
 <meta
   http-equiv="Content-Type"
   content="text/html; charset=UTF-8" />
-<title>Eclipse Project Release Notes 4.10</title>
+<title>Eclipse Project Release Notes 4.11</title>
 <!-- Please validate as "xhtml1 strict", at
-https://validator.w3.org/check?uri=http%3A%2F%2Fwww.eclipse.org%2Feclipse%2Fdevelopment%2Freadme_eclipse_4.10.html;ss=1
+https://validator.w3.org/check?uri=http%3A%2F%2Fwww.eclipse.org%2Feclipse%2Fdevelopment%2Freadme_eclipse_4.11.html;ss=1
 (It must be "on website" to validate.)
 -->
 </head>
@@ -19,12 +19,12 @@
   <p>
     <a
       class="mozTocH1"
-      name="mozTocId299852">Release 4.10</a>
+      name="mozTocId299852">Release 4.11</a>
   </p>
   <p>
     <a
       class="mozTocH1"
-      name="mozTocId299852">Last revised Dec 4, 2018</a>
+      name="mozTocId299852">Last revised Feb 25, 2019</a>
   </p>
   <!-- 
 This following link to www.eclipse.org should be commented out
@@ -34,7 +34,7 @@
 to "the latest version" since there _might_ be changes made 
 after the release.
   <p>
-    The latest version of this document can be found on the web at <a href="https://www.eclipse.org/eclipse/development/readme_eclipse_4.10.php">Eclipse Release Notes 4.10</a>. There may or may
+    The latest version of this document can be found on the web at <a href="https://www.eclipse.org/eclipse/development/readme_eclipse_4.11.php">Eclipse Release Notes 4.11</a>. There may or may
     not be changes made after the product is released. You can tell by checking the "last revised" date near the top of this page.
   </p>
 -->
@@ -57,7 +57,7 @@
         <li><a href="#mozTocId315234">Target Operating Environments</a></li>
         <li><a href="#mozTocId569479">Compatibility with Previous Releases</a>
           <ol>
-            <li><a href="#mozTocId324309">Compatibility of Release 4.10 with 4.9</a></li>
+            <li><a href="#mozTocId324309">Compatibility of Release 4.11 with 4.10</a></li>
           </ol></li>
         <li><a href="#mozTocId214943">Known Issues</a>
           <ol>
@@ -151,7 +151,6 @@
                 <li><a href="#mozTocId73293">Importing in Eclipse application fails if plug-in exists in host workspace</a></li>
                 <li><a href="#mozTocId914239">Reusing a workspace after changing architectures silently breaks PDE models</a></li>
                 <li><a href="#mozTocId624312">Missing @since tag API Tools problems on interface fields containing @noreference tag</a></li>
-                <li><a href="#mozTocId624319">"Premature end of file" error in creating a new target file</a></li>
                </ol></li>
                 
               </ol></li>
@@ -173,13 +172,14 @@
           </ol></li>
         <li><a href="#mozTocId638978">Interoperability with Previous Releases</a>
           <ol>
-            <li><a href="#mozTocId759237">Interoperability of Release 4.9 with previous releases</a>
+            <li><a href="#mozTocId759237">Interoperability of Release 4.11 with previous releases</a>
               <ol>
-                <li><a href="#mozTocId226004">Sharing projects between heterogeneous Eclipse 4.10 and 4.9</a></li>
-                <li><a href="#mozTocId574781">Using Eclipse 4.10 to develop plug-ins that work in Eclipse 4.9</a></li>
+                <li><a href="#mozTocId226004">Sharing projects between heterogeneous Eclipse 4.11 and 4.10</a></li>
+                <li><a href="#mozTocId574781">Using Eclipse 4.11 to develop plug-ins that work in Eclipse 4.10</a></li>
               </ol></li>
           </ol></li>
         <li><a href="#mozTocId317294">Appendix: Execution Environment by Bundle</a></li>
+      </ol></li>
   </ol>
   <h2 id="TargetOperatingEnvironments2">
     <a
@@ -190,7 +190,7 @@
   <p>Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself. Portions are
     targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java
     5, etc).</p>
-  <p>In general, the 4.10 release of the Eclipse Project is developed on Java SE 8 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs.</p>
+  <p>In general, the 4.11 release of the Eclipse Project is developed on Java SE 8 VMs. As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs.</p>
   <p>
     <a href="#appendix">Appendix 1</a> contains a table that indicates the class library level required for each bundle.
   </p>
@@ -201,9 +201,9 @@
     problems with running Eclipse on a reference platform.
   </p>
   <p>
-    Eclipse 4.10 is tested and validated on a number of reference platforms. For the complete list, see <a
-      href="https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#target_environments">Target Environments in the
-      4.10 Plan</a>.
+    Eclipse 4.11 is tested and validated on a number of reference platforms. For the complete list, see <a
+      href="https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_11.xml#target_environments">Target Environments in the
+      4.11 Plan</a>.
   </p>
   <p>
     As stated above, <i>we expect that Eclipse works fine on other current Java VM and OS versions but we cannot flag these as reference platforms without significant community support for testing
@@ -222,42 +222,42 @@
   <h3>
     <a
       class="mozTocH3"
-      name="mozTocId324309">Compatibility of Release 4.10 with 4.9</a>
+      name="mozTocId324309">Compatibility of Release 4.11 with 4.10</a>
   </h3>
   <p>
     <a
       class="mozTocH3"
-      name="mozTocId324309">Eclipse 4.10 is compatible with Eclipse 4.9 (and all earlier 4.x and 3.x versions).</a>
+      name="mozTocId324309">Eclipse 4.11 is compatible with Eclipse 4.10 (and all earlier 4.x and 3.x versions).</a>
   </p>
   <p>
     <a
       class="mozTocH3"
-      name="mozTocId324309"> <strong>API Contract Compatibility:</strong> Eclipse SDK 4.10 is upwards contract-compatible with Eclipse SDK 4.9 except in those areas noted in the
-    </a><a href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_10_porting_guide.html"><em>Eclipse 4.10 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension points
-    will need to be ported to Eclipse SDK 4.10 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 4.10 APIs would ensure compliance with
-    Eclipse SDK 4.9 APIs. Refer to <a href="https://wiki.eclipse.org/Evolving_Java-based_APIs"><em>Evolving Java-based APIs</em></a> for a discussion of the kinds of API changes that maintain contract
+      name="mozTocId324309"> <strong>API Contract Compatibility:</strong> Eclipse SDK 4.11 is upwards contract-compatible with Eclipse SDK 4.10 except in those areas noted in the
+    </a><a href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_11_porting_guide.html"><em>Eclipse 4.11 Plug-in Migration Guide</em></a>. Programs that use affected APIs and extension points
+    will need to be ported to Eclipse SDK 4.11 APIs. Downward contract compatibility is not supported. There is no guarantee that compliance with Eclipse SDK 4.11 APIs would ensure compliance with
+    Eclipse SDK 4.10 APIs. Refer to <a href="https://wiki.eclipse.org/Evolving_Java-based_APIs"><em>Evolving Java-based APIs</em></a> for a discussion of the kinds of API changes that maintain contract
     compatibility.
   </p>
   <p>
-    <strong>Binary (plug-in) Compatibility:</strong> Eclipse SDK 4.10 is upwards binary-compatible with Eclipse SDK 4.9 except in those areas noted in the <a
-      href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_10_porting_guide.html"><em>Eclipse 4.10 Plug-in Migration Guide</em> </a>. Downward plug-in compatibility is not supported.
-    Plug-ins for Eclipse SDK 4.9 will not be usable in Eclipse SDK 4.9. Refer to <a href="https://wiki.eclipse.org/Evolving_Java-based_APIs"> <em>Evolving Java-based APIs</em></a> for a discussion of
+    <strong>Binary (plug-in) Compatibility:</strong> Eclipse SDK 4.11 is upwards binary-compatible with Eclipse SDK 4.10 except in those areas noted in the <a
+      href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_11_porting_guide.html"><em>Eclipse 4.11 Plug-in Migration Guide</em> </a>. Downward plug-in compatibility is not supported.
+    Plug-ins for Eclipse SDK 4.11 will not be usable in Eclipse SDK 4.10. Refer to <a href="https://wiki.eclipse.org/Evolving_Java-based_APIs"> <em>Evolving Java-based APIs</em></a> for a discussion of
     the kinds of API changes that maintain binary compatibility.
   </p>
   <p>
-    <strong>Source Compatibility:</strong> Eclipse SDK 4.10 is upwards source-compatible with Eclipse SDK 4.9 except in the areas noted in the <a
-      href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_10_porting_guide.html"><em>Eclipse 4.10 Plug-in Migration Guide</em> </a>. This means that source files written to use Eclipse
-    SDK 4.10 APIs might successfully compile and run against Eclipse SDK 4.10 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK
+    <strong>Source Compatibility:</strong> Eclipse SDK 4.11 is upwards source-compatible with Eclipse SDK 4.10 except in the areas noted in the <a
+      href="http://www.eclipse.org/eclipse/development/porting/eclipse_4_11_porting_guide.html"><em>Eclipse 4.11 Plug-in Migration Guide</em> </a>. This means that source files written to use Eclipse
+    SDK 4.11 APIs might successfully compile and run against Eclipse SDK 4.10 APIs, although this is not guaranteed. Downward source compatibility is not supported. If source files use new Eclipse SDK
     APIs, they will not be usable with an earlier version of the Eclipse SDK.
   </p>
   <p>
-    <strong>Workspace Compatibility:</strong> Eclipse SDK 4.10 is upwards workspace-compatible with earlier 3.x and 4.x versions of the Eclipse SDK unless noted. This means that workspaces and projects
-    created with Eclipse SDK 4.9, 4.8, 4.7, 4.6, 4.5, 4.4, 4.3, 4.2, ... 3.0 can be successfully opened by Eclipse SDK 4.10 and upgraded to a 4.10 workspace. This includes both hidden metadata, which is localized to a
+    <strong>Workspace Compatibility:</strong> Eclipse SDK 4.11 is upwards workspace-compatible with earlier 3.x and 4.x versions of the Eclipse SDK unless noted. This means that workspaces and projects
+    created with Eclipse SDK 4.10, 4.9, 4.8, 4.7, 4.6, 4.5, 4.4, 4.3, 4.2, ... 3.0 can be successfully opened by Eclipse SDK 4.11 and upgraded to a 4.11 workspace. This includes both hidden metadata, which is localized to a
     particular workspace, as well as metadata files found within a workspace project (e.g., the .project file), which may propagate between workspaces via file copying or team repositories. Individual
-    plug-ins developed for Eclipse SDK 4.10 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 4.10 plug-in developers are
+    plug-ins developed for Eclipse SDK 4.11 should provide similar upwards compatibility for their hidden and visible workspace metadata created by earlier versions; 4.11 plug-in developers are
     responsible for ensuring that their plug-ins recognize metadata from earlier versions and process it appropriately. User interface session state may be discarded when a workspace is upgraded.
-    Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 4.10 will be unusable with a product based on an earlier version of Eclipse. Visible
-    metadata files created (or overwritten) by Eclipse 4.10 will generally be unusable with earlier versions of Eclipse.
+    Downward workspace compatibility is not supported. A workspace created (or opened) by a product based on Eclipse 4.11 will be unusable with a product based on an earlier version of Eclipse. Visible
+    metadata files created (or overwritten) by Eclipse 4.11 will generally be unusable with earlier versions of Eclipse.
   </p>
   <p>
     <strong>Non-compliant usage of API's</strong>: All non-API methods and classes, and certainly everything in a package with "internal" in its name or x-internal in the bundle manifest entry, are
@@ -299,7 +299,7 @@
       <li>Running Eclipse with Java SE 9 and above may require additional configuration. Please refer to <a href="https://wiki.eclipse.org/Configure_Eclipse_for_Java_9">this page</a> for more details.</li>
     <li><a
       class="mozTocH4"
-      name="mozTocId693657">As shown </a><a href="#TargetOperatingEnvironments">above</a>, Eclipse 4.10 requires at least a Java SE 8. Perhaps an older version of the VM is being found in your path. To
+      name="mozTocId693657">As shown </a><a href="#TargetOperatingEnvironments">above</a>, Eclipse 4.11 requires at least a Java SE 8. Perhaps an older version of the VM is being found in your path. To
       explicitly specify which VM to run with, use the Eclipse <code>-vm</code> command-line argument. (See also the <a href="#RunningEclipse">Running Eclipse</a> section below.)</li>
     <li>Running Eclipse on Gentoo Linux may result in the following error message:
       <div style="margin-left: 40px;">
@@ -406,9 +406,9 @@
     <li><a href="http://download.eclipse.org/eclipse/downloads/">http://download.eclipse.org/eclipse/downloads/</a></li>
   </ul>
   <p>
-    It is imperative that 64-bit builds are downloaded and used if a 64-bit Java runtime environment has been installed. Below is a sample tarball names of version 4.10 of the Eclipse SDK packaged
+    It is imperative that 64-bit builds are downloaded and used if a 64-bit Java runtime environment has been installed. Below is a sample tarball names of version 4.11 of the Eclipse SDK packaged
     for 64-bit processors.<br />
-    <code>eclipse-SDK-4.10-linux-gtk-x86_64.tar.gz (64-bit)</code>
+    <code>eclipse-SDK-4.11-linux-gtk-x86_64.tar.gz (64-bit)</code>
   </p>
   <p>
     To run Eclipse with an alternate Java runtime environment, the path to the Java virtual machine's binary must be identified. With an Eclipse installation from the distribution, altering the $PATH
@@ -1400,17 +1400,7 @@
       create an API Tools filter for the missing @since tag problem. This filter can be removed as soon as the API baseline has been regenerated. (bug </a><a
       href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=402393">402393</a>)
   </p>
-    <h4>
-    <a
-      class="mozTocH4"
-      name="mozTocId624319">"Premature end of file" error in creating a new target file</a>
-  </h4>
-  <p>
-    <a
-      class="mozTocH4"
-       name="mozTocId624319">[4.9] On Mac and linux machines, there is a "Premature end of file" error in creating a new target file. Restarting eclipse may fix this issue. (bug </a><a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=541678">541678</a>)
-
-  </p>
+  
   <h2 id="RunningEclipse">
     <a
       class="mozTocH2"
@@ -1421,7 +1411,7 @@
       class="mozTocH2"
       name="mozTocId19817"> After installing the Eclipse SDK in a directory, you can start the Workbench by running the Eclipse executable included with the release (you also need a Java SE 8 JRE,
       not included with the Eclipse SDK). On Windows, the executable file is called <samp>eclipse.exe</samp> , and is located in the <code>eclipse</code> sub-directory of the install. If installed at
-      <code>c:\eclipse-SDK-4.10-win32</code> , the executable is <code>c:\eclipse-SDK-4.10-win32\eclipse\eclipse.exe</code> . <b>Note:</b> Set-up on most other operating environments is analogous.
+      <code>c:\eclipse-SDK-4.11-win64</code> , the executable is <code>c:\eclipse-SDK-4.11-win64\eclipse\eclipse.exe</code> . <b>Note:</b> Set-up on most other operating environments is analogous.
       Special instructions for Mac OS X are listed
     </a><a href="#macosx">below</a>.
   </p>
@@ -1667,66 +1657,66 @@
   <h3>
     <a
       class="mozTocH3"
-      name="mozTocId759237">Interoperability of Release 4.10 with previous releases</a>
+      name="mozTocId759237">Interoperability of Release 4.11 with previous releases</a>
   </h3>
   <h4>
     <a
       class="mozTocH4"
-      name="mozTocId226004">Sharing projects between heterogeneous Eclipse 4.10 and 4.9</a>
+      name="mozTocId226004">Sharing projects between heterogeneous Eclipse 4.11 and 4.10</a>
   </h4>
   <p>Special care is required when a project in a team repository is being loaded and operated on by developers using Eclipse-based products based on different feature or plug-in versions. The
     general problem is that the existence, contents, and interpretation of metadata files in the workspaces may be specific to a particular feature or plug-in version, and differ between versions. The
     workspace compatibility guarantees only cover cases where all developers upgrade their Eclipse workspaces in lock step. In those cases there should be no problem with shared metadata. However,
-    when some developers are working in Eclipse 4.10 while others are working in Eclipse 3.x, there are no such guarantees. This section provides advice for what to do and not to do. It addresses the
+    when some developers are working in Eclipse 4.11 while others are working in Eclipse 3.x, there are no such guarantees. This section provides advice for what to do and not to do. It addresses the
     specific issues with the Eclipse SDK.</p>
-  <p>The typical failure mode is noticed by the 4.10 user. 4.10 metadata is lost when a 4.9 user saves changes and then commits the updated metadata files to the repository. Here's how things
+  <p>The typical failure mode is noticed by the 4.11 user. 4.10 metadata is lost when a 4.11 user saves changes and then commits the updated metadata files to the repository. Here's how things
     typically go awry:</p>
   <ul>
-    <li>A user working in Eclipse 4.10 creates or modifies a project in a way that results in changes to a shared metadata file that rely on 4.10-specific information. The user then commits the
+    <li>A user working in Eclipse 4.11 creates or modifies a project in a way that results in changes to a shared metadata file that rely on 4.11-specific information. The user then commits the
       updated project files, including the shared metadata file, to the shared repository.</li>
     <li><a
       class="mozTocH4"
-      name="mozTocId226004">Another user working in Eclipse 4.9 or earlier shares this project from the same repository. The 4.10-specific information in the shared metadata file is not understood
-        by Eclipse 4.9, and is generally discarded or ignored without warning. The user modifies the project in a way that results in changes to the shared metadata file, causing the shared metadata
-        file to be rewritten without any of the 4.10-specific information. The user commits the updated project files, including the shared metadata file, to the shared repository. The user is
+      name="mozTocId226004">Another user working in Eclipse 4.10 or earlier shares this project from the same repository. The 4.11-specific information in the shared metadata file is not understood
+        by Eclipse 4.10, and is generally discarded or ignored without warning. The user modifies the project in a way that results in changes to the shared metadata file, causing the shared metadata
+        file to be rewritten without any of the 4.11-specific information. The user commits the updated project files, including the shared metadata file, to the shared repository. The user is
         generally unaware that shared information has just been lost as a result of their actions.</a></li>
     <li><a
       class="mozTocH4"
-      name="mozTocId226004">A user working in Eclipse 4.10 picks up the changes to a project from the shared repository, including the updated shared metadata file. The user may be unaware that
+      name="mozTocId226004">A user working in Eclipse 4.11 picks up the changes to a project from the shared repository, including the updated shared metadata file. The user may be unaware that
         they have just taken a retrograde step until later when things start to malfunction.</a></li>
   </ul>
   <p>
     <a
       class="mozTocH4"
-      name="mozTocId226004">Here are some things to watch out for when sharing projects between Eclipse 4.9 and earlier releases:</a>
+      name="mozTocId226004">Here are some things to watch out for when sharing projects between Eclipse 4.11 and earlier releases:</a>
   </p>
   <ul>
     <li><a
       class="mozTocH4"
-      name="mozTocId226004"><b>Virtual folders</b> - Eclipse 4.10 supports a notion of <i>virtual folders</i> that did not exist in Eclipse 3.5 or earlier. If such virtual folders are created in
-        4.10, and the project is subsequently loaded into an Eclipse 3.5 or earlier workspace, these folders will not be recognized. Recommendation: avoid creating virtual folders where project
+      name="mozTocId226004"><b>Virtual folders</b> - Eclipse 4.11 supports a notion of <i>virtual folders</i> that did not exist in Eclipse 3.5 or earlier. If such virtual folders are created in
+        4.11, and the project is subsequently loaded into an Eclipse 3.5 or earlier workspace, these folders will not be recognized. Recommendation: avoid creating virtual folders where project
         compatibility with Eclipse 3.5 or earlier is required.</a></li>
     <li><a
       class="mozTocH4"
-      name="mozTocId226004"><b>Resource filters</b> - Eclipse 4.10 supports a notion of <i>resource filters</i> that did not exist in Eclipse 3.5 or earlier. If such filters are added to resources
-        in 4.10, and the project is subsequently loaded into an Eclipse 3.5 or earlier workspace, these filters will not be recognized. Recommendation: avoid creating resource filters where project
+      name="mozTocId226004"><b>Resource filters</b> - Eclipse 4.11 supports a notion of <i>resource filters</i> that did not exist in Eclipse 3.5 or earlier. If such filters are added to resources
+        in 4.11, and the project is subsequently loaded into an Eclipse 3.5 or earlier workspace, these filters will not be recognized. Recommendation: avoid creating resource filters where project
         compatibility with Eclipse 3.5 or earlier is required.</a></li>
     <li><a
       class="mozTocH4"
-      name="mozTocId226004"><b>Predefined path variables</b> - Eclipse 4.10 supports a set of built in path variables that can be used as the basis for linked resource locations. Such variables
+      name="mozTocId226004"><b>Predefined path variables</b> - Eclipse 4.11 supports a set of built in path variables that can be used as the basis for linked resource locations. Such variables
         will not be defined automatically in Eclipse 3.5 or earlier. If compatibility with 3.5 or earlier workspace is required, users on 3.5 or earlier workspaces will need to define such path
         variables manually.</a></li>
   </ul>
   <h4>
     <a
       class="mozTocH4"
-      name="mozTocId574781">Using Eclipse 4.10 to develop plug-ins that work in Eclipse 4.9</a>
+      name="mozTocId574781">Using Eclipse 4.11 to develop plug-ins that work in Eclipse 4.10</a>
   </h4>
   <p>
     <a
       class="mozTocH4"
-      name="mozTocId574781"> It is also possible (and reasonable) to use Eclipse 4.10 to develop a plug-in intended to work in Eclipse 4.9 or earlier. Use the <b>Plug-in Development &gt; Target
-        Platform </b>preference page to locate non-workspace plug-ins in an Eclipse 4.9 install. This ensures that the code for your plug-in is being compiled and tested against Eclipse 4.9 APIs,
+      name="mozTocId574781"> It is also possible (and reasonable) to use Eclipse 4.11 to develop a plug-in intended to work in Eclipse 4.10 or earlier. Use the <b>Plug-in Development &gt; Target
+        Platform </b>preference page to locate non-workspace plug-ins in an Eclipse 4.10 install. This ensures that the code for your plug-in is being compiled and tested against Eclipse 4.10 APIs,
       extension points, and plug-ins. (The above list of concerns do not apply since they affect the layout and interpretation of files in the plug-in <i>project</i> but none affect the actual
       deployed form of the plug-in.)
     </a>
@@ -1744,7 +1734,7 @@
     <a
       class="mozTocH2"
       name="mozTocId317294"> See the table in the </a><a
-      href="https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_10.xml#appendix">Eclipse 4.10 Project Plan Appendix</a> for
+      href="https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_11.xml#appendix">Eclipse 4.11 Project Plan Appendix</a> for
     the list of the minimum execution environment (Java class library) requirements of each bundle.
   </p>
   <hr />
@@ -1753,6 +1743,6 @@
   <p>Microsoft, Windows, Windows NT, Vista, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.</p>
   <p>Apple and Mac OS are trademarks of Apple Computer, Inc., registered in the U.S. and other countries.</p>
   <p>Other company, product, and service names may be trademarks or service marks of others.</p>
-  <p>(c) Copyright Eclipse Contributors 2009, 2018</p>
+  <p>(c) Copyright Eclipse Contributors 2009, 2019</p>
 </body>
 </html>