update links in Markdown documentation

Author: danthe1st

README.md

@@ -65,21 +65,17 @@ Integration builds
 
 The integrations (nightly) build jobs are hosted on Jenkins instance https://ci.eclipse.org/releng/job/Builds/.
 
-The job with the highest release number is the one that builds nightly SDK build, like https://ci.eclipse.org/releng/job/Builds/job/I-build-4.36/ job for 4.36 SDK.
+The job with the highest release number is the one that builds nightly SDK build, like https://ci.eclipse.org/releng/job/Builds/job/I-build-4.38/ job for 4.38 SDK.
 
 - The build artifacts and test results are accessible at https://download.eclipse.org/eclipse/downloads/
 - If the tests fail to start, test jobs for each platform can be found at https://ci.eclipse.org/releng/job/AutomatedTests/
-- If the build is successful but SDK is broken and shouldn't be used, the build can be marked as unstable via https://ci.eclipse.org/releng/job/Builds/job/markUnstable/
-- Weekly maven snapshots are [built on Jenkins](https://ci.eclipse.org/releng/view/Publish%20to%20Maven/) and available at https://repo.eclipse.org/content/repositories/eclipse-snapshots/
+- If the build is successful but SDK is broken and shouldn't be used, the build can be marked as unstable via https://ci.eclipse.org/releng/job/Builds/job/markBuild/
+- Weekly maven snapshots are [built on Jenkins](https://ci.eclipse.org/releng/job/Releng/job/deployToMaven/) and available at https://repo.eclipse.org/content/repositories/eclipse-snapshots/
 
 Milestone and release tasks
 -----------------
 See [Releng-Tasks 2.0](RELEASE.md) (includes links to schedule, calendar etc)
 
-Performance Tests
------------------
-See [Performance README.md](production/README.md)
-
 How to contribute
 -----------------
 Contributions to Eclipse Platform are most welcome. There are many ways to contribute,

RELEASE.md

@@ -41,12 +41,12 @@
          - For Milestones/RC promotions, this should automatically run the [Publish Promoted Build](https://ci.eclipse.org/releng/job/Releng/job/publishPromotedBuild/) job to make the promoted build immediatly visible on the download page.
        * Contribute to SimRel
          - If you have not already set up SimRel you can do so using Auto Launch [here](https://www.eclipse.org/setups/installer/?url=https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/interim/SimultaneousReleaseTrainConfiguration.setup&show=true)
-         - Clone [org.eclipse.simrel.build](https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git) (Should have been done by the installer during set up, but make sure you have latest).
+         - Clone [simrel.build](https://github.com/eclipse-simrel/simrel.build) (Should have been done by the installer during set up, but make sure you have latest).
            1. Open simrel.aggr in Eclipse
            2. Change to the properties view
-           3. Select Contribution:Eclipse > Mapped Repository
-           4. Update the Location property to the "Specific repository for building against" in the mailtemplate.txt from promotion.
-           5. Commit Simrel updates to Gerrit
+           3. Select `Contribution:Eclipse` > `Mapped Repository`
+           4. Update the Location property to the "Specific repository for building against" in the `mailtemplate.txt` from promotion.
+           5. Commit Simrel updates to GitHub
               - Message should use year-month format, i.e "Simrel updates for Eclipse and Equinox for 2022-06 M1"
      * **After RC1**
        * Comment on EMF, ECF and Orbit issues to ask for final release builds.
@@ -63,21 +63,20 @@ Tasks that need to be completed before Friday
     - A script to create this issue exists [here](scripts/GAReleasePrep.sh) for those who have the hub cli tool installed.
   * **New & Noteworthy**
     Currently this is handled by @lshanmug who will
-    - Create a tracking issue in the [eclipse.platform.common](https://github.com/eclipse-platform/eclipse.platform.common) repo (see [N&N for 4.26](https://github.com/eclipse-platform/eclipse.platform.common/pull/93) as an example).
+    - Create a tracking issue in the [eclipse.platform.releng.aggregator](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/) repo (see [N&N for 4.36](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/3063) as an example).
     - Update the WhatsNew files and folders for the doc bundles.
   * **Readme**
     Currently handled by @SarikaSinha
     - Create a tracking issue in [www.eclipse.org-eclipse](https://github.com/eclipse-platform/www.eclipse.org-eclipse) (see [Readme file for 4.26](https://github.com/eclipse-platform/www.eclipse.org-eclipse/issues/24) as an example).
     - Add Readme files and update generatation scripts.
   * **Acknowledgements**
-    - Create a tracking issue in [www.eclipse.org-eclipse](https://github.com/eclipse-platform/www.eclipse.org-eclipse) and link it to the main release issue in eclipse.platform.releng.aggregator.
-    - Create a new acknowledgements file for the current release and add it to [www.eclipse.org-eclipse/development](https://github.com/eclipse-platform/www.eclipse.org-eclipse/tree/master/development).
-    - The previous acknowledgement files are there for reference.
+    - The releng tooling automatically runs the [Generate Acknowledgements](https://github.com/eclipse-platform/www.eclipse.org-eclipse/actions/workflows/generateAcknowledgements.yml) GitHub Actions build which creates a pull request in the [www.eclipse.org-eclipse repository](https://github.com/eclipse-platform/www.eclipse.org-eclipse/pulls)
+    - This pull request should be reviewed to ensure all bot accounts are excluded and that there are no issues with the chosen inconsistent author names.
   * **Migration Guide**
-    - Create a tracking issue in [eclipse.platform.common](https://github.com/eclipse-platform/eclipse.platform.common) and link it to the main release issue in eclipse.platform.releng.aggregator.
-    - Every release a new porting guide and folder need to be added to [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.jdt.doc.isv/porting), named with the version being migrated *to*.
+    - Create a tracking issue in [eclipse.platform.releng.aggregator](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues) and link it to the main release issue.
+    - Every release a new porting guide and folder need to be added to [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv/porting), named with the version being migrated *to*.
       - i.e `eclipse_4_27_porting_guide.html` is for migrating from 4.26 tp 4.27.
-    - Update topics_Porting.xml in [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.jdt.doc.isv) and [eclipse.platform.common/bundles/org.eclipse.platform.doc.isv](https://github.com/eclipse-platform/eclipse.platform.common/tree/master/bundles/org.eclipse.platform.doc.isv)
+    - Update `topics_Porting.xml` in [eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/eclipse.platform.common/bundles/org.eclipse.jdt.doc.isv) and [eclipse.platform.common/bundles/org.eclipse.platform.doc.isv](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/eclipse.platform.common/bundles/org.eclipse.platform.doc.isv)
     - Update the name of the proting html document in [eclipse.platform/platform/org.eclipse.platform/intro/migrateExtensionContent.xml](https://github.com/eclipse-platform/eclipse.platform/blob/master/platform/org.eclipse.platform/intro/migrateExtensionContent.xml) 
   * **SWT Javadoc bash**
     Currently handled by @niraj-modi 
@@ -134,7 +133,7 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
   - Issue for the 2023 releases is [https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336](https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/2336)
 
 #### **Update Jenkins for the next Release:**
-  - Run the [Create Jobs](https://ci.eclipse.org/releng/job/Create%20Jobs/) job in Jenkins.  
+  - Run the [Create Jobs](https://ci.eclipse.org/releng/job/CreateJobs/) job in Jenkins.
     But until the preparation work has completed, the new I-builds should not be triggered in order to avoid undesired interference. To ensure this, either
     - Run the `Create Jobs` job only after all preparation work is reviewed and submitted and the first I-build can run.
     - Disable the new `I-build` job until it's ready to run it the first time.

RELENG.md

@@ -4,21 +4,21 @@
 
 **Create Jobs**
 
-The (Create Jobs)[https://ci.eclipse.org/releng/job/Create%20Jobs/] job is used to populate the jenkins subfolders with the jobs defined in (JenkinsJobs)[JenkinsJobs] groovy files. There are 2 Process Job DSLs steps, the first looks for FOLDER.groovy files and creates the folders, the second creates the jobs themselves.
+The [Create Jobs](https://ci.eclipse.org/releng/job/CreateJobs/) job is used to populate the jenkins subfolders with the jobs defined in [JenkinsJobs](JenkinsJobs) groovy files. There are 2 Process Job DSLs steps, the first looks for FOLDER.groovy files and creates the folders, the second creates the jobs themselves.
 
-Create Jobs *must be run manually*. Unfortunately JobDSL needs to be run by a specific user, so the build cannot be automatically started by a timer or when it detects jenkins changes without installing an additional plugin like (Authorize Project)[https://plugins.jenkins.io/authorize-project/], which supposedly still works but is abandoned and I (Sam) have not had time to investigate further or find alternatives. This means that while any committer can make changes to the Jenkins Jobs in git, someone with Jenkins rights will have to start the build to implement those changes.
+Create Jobs *must be run manually*. Unfortunately JobDSL needs to be run by a specific user, so the build cannot be automatically started by a timer or when it detects jenkins changes without installing an additional plugin like [Authorize Project](https://plugins.jenkins.io/authorize-project/]) which supposedly still works but is abandoned and I (Sam) have not had time to investigate further or find alternatives. This means that while any committer can make changes to the Jenkins Jobs in git, someone with Jenkins rights will have to start the build to implement those changes.
 
 Obsolete jobs have to be deleted manually.
 They are not deleted automatically as some may be are still in use for a short time (e.g. Y-builds if a java-release is imminent) or to serve as reference in case the new jobs have problems.
 
 **The JenkinsJobs Folder**
 
-As a general rule, the (JenkinsJobs)[JenkinsJobs] folder should match the layout of Jenkins itself. Every subfolder should contain a (FOLDER.groovy)[JenkinsJobs/Builds/FOLDER.groovy] file as well as groovy files for all individual jobs. 
+As a general rule, the [JenkinsJobs](./JenkinsJobs) folder should match the layout of Jenkins itself. Every subfolder should contain one `.jenkinsfile` per individual pipeline. 
 
 Note: JobDSL does also support the creation of Views, so those can be added at some point but someone will either have to manually keep them up to date with the desired jobs or write a script to keep them up-to-date.
 
-Many jobs have the release version in the job name because it is required for results parsing (i.e. the (automated tests)[https://ci.eclipse.org/releng/job/AutomatedTests/]).
-In order to minimize manual labor the currently active streams are listed in the (buildConfigurations.json)[JenkinsJobs/buildConfigurations.json] file.
+Many jobs have the release version in the job name because it is required for results parsing (i.e. the [automated tests](https://ci.eclipse.org/releng/job/AutomatedTests/)).
+In order to minimize manual labor the currently active streams are listed in the [buildConfigurations.json](./JenkinsJobs/buildConfigurations.json) file.
 Version dependent jobs then parse this file during creation and make a job for each stream.
 
 **New Jobs**
@@ -30,10 +30,10 @@ Adding a job to Jenkins should be as easy as adding a new groovy file to git, bu
   - No spaces, this is just for the good of scripts etc. The job NAME is used in the url, but you can always add a `displayName` field if you want the job to appear with a more natural looking name on the page. See (Releng/deployToMaven)[JenkinsJobs/Releng/FOLDER.groovy] as an example.
   - The folder needs to be part of the job name, otherwise Jenkins will just create the job at the dashboard level.
 * **job vs pipelineJob**
-  - Anything that can build on a regular jenkins node or via an available lable uses the (job)[https://jenkinsci.github.io/job-dsl-plugin/#path/job] template.
-  - Anything that defines its own kubernetes pod needs to be a (pipelineJob)[https://jenkinsci.github.io/job-dsl-plugin/#path/pipelineJob]
+  - Anything that can build on a regular jenkins node or via an available lable uses the [job](https://jenkinsci.github.io/job-dsl-plugin/#path/job) template.
+  - Anything that defines its own kubernetes pod needs to be a [pipelineJob](https://jenkinsci.github.io/job-dsl-plugin/#path/pipelineJob)
 * **Script Formatting** You can use `'''`triple apostrophes`'''` to define multiline scripts. I've found it's best to start the script on the same line and not the next, otherwise you end up with blank space at the top of the script step in Jenkins which can break the build (like the arm64 smoke tests).
-* To see what plugins are installed and what methods are available in the Releng Jenkins you can consult the (api viewer)[https://ci.eclipse.org/releng/plugin/job-dsl/api-viewer/index.html#].
+* To see what plugins are installed and what methods are available in the Releng Jenkins you can consult the [api viewer](https://ci.eclipse.org/releng/plugin/job-dsl/api-viewer/index.html#).
 
 
 # Updating Java Versions
@@ -44,9 +44,9 @@ Every 6 months there is a new Java release which requires additional builds and
 The **Y-build** is a full sdk build with the new java version for testing. 
 
 The **P-build** is a patch build that contains modified plugins designed to be installed on top of the current I-build to test the new java version.
-They are now managed by the JDT-project itself in (org.eclipse.jdt.releng)[https://github.com/eclipse-jdt/eclipse.jdt/tree/master/org.eclipse.jdt.releng].
+They are now managed by the JDT-project itself in [org.eclipse.jdt.releng](https://github.com/eclipse-jdt/eclipse.jdt/tree/master/org.eclipse.jdt.releng).
 
-The builds themselves and their unit tests are in the (Y Builds)[JenkinsJobs/YBuilds] folder in git and the (Y Builds)[https://ci.eclipse.org/releng/job/YBuilds/] folder in jenkins.
+The builds themselves and their unit tests are in the [build.jeninsfile](./JenkinsJobs/Builds/build.jenkinsfile) in GitHub and the [Y Builds](https://ci.eclipse.org/releng/job/YBuilds/) folder in jenkins.
 
 ## Setting Up New Builds