Update dependencies to Eclipse 2025-12, replace obsolete target files

[Dietrich Travkin (travkin79)]

As requested by Sheng Chen (@jdneo), I prepared a new target platform definition for Eclipse 2025-12 (Eclipse 4.38).

This PR

• adds new targets 2025-12.target (for Eclipse 4.38 and later), 2024-12.target for terminal.tm bundle and Eclipse 4.36 and earlier
• replaces the obsolete target files in Maven build
• updates documentation
• replaces JDK 17 with JDK 21 (since Eclipse 2025-12 requires JDK 21)
• adds a Maven (m2e) launch config for mvn clean verify
• sets projects' encoding to UTF-8
• unifies output folders to target/classes
• fixes a compile error in Eclipse, avoids "OSGi access rules not enforced by classpath access rules, which can lead to classloading errors at runtime." error message

[Copilot]

Pull request overview

Updates the GitHub Copilot for Eclipse build and development setup to target Eclipse 2025-12 (Eclipse 4.38) and Java 21, while removing legacy/obsolete target definitions and the legacy TM-terminal bundle intended for older Eclipse versions.

Changes:

• Introduces a new target definition for Eclipse 2025-12 and updates Tycho/Maven to build against it.
• Migrates bundle execution environments and Eclipse project settings from Java 17 to Java 21; standardizes encodings/output folders.
• Removes obsolete target files and deletes the legacy com.microsoft.copilot.eclipse.ui.terminal.tm bundle.

Reviewed changes

Copilot reviewed 66 out of 66 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
target-tm-terminal.target	Removed obsolete TM-terminal target definition.
target-terminal.target	Removed obsolete terminal target definition.
target-platforms/2025-12.target	Added new Eclipse 2025-12 target platform definition (incl. Orbit deps).
pom.xml	Drops legacy TM-terminal module and points Tycho at the new 2025-12 target + JavaSE-21.
launch/Verify Copilot for Eclipse.launch	Adds an m2e launch config for mvn clean verify.
launch/plugin_debug_configuration.launch	Updates PDE launch JRE from Java 17 to Java 21.
CONTRIBUTING.md	Updates dev prerequisites and target-platform guidance to 2025-12 / Java 21.
com.microsoft.copilot.eclipse.ui/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.ui/build.properties	Normalizes source/output folder entries.
com.microsoft.copilot.eclipse.ui/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.ui/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.ui/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.ui.test/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.ui.test/build.properties	Normalizes source/output folder entries.
com.microsoft.copilot.eclipse.ui.test/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.ui.test/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.ui.test/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.ui.terminal/pom.xml	Switches Tycho target file to the new 2025-12 target.
com.microsoft.copilot.eclipse.ui.terminal/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.ui.terminal/build.properties	Unifies output folder to target/classes/.
com.microsoft.copilot.eclipse.ui.terminal/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.ui.terminal/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.ui.terminal/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.ui.terminal.tm/src/com/microsoft/copilot/eclipse/ui/terminal/tm/RunInTerminalTool.java	Removes legacy TM-terminal implementation.
com.microsoft.copilot.eclipse.ui.terminal.tm/pom.xml	Removes legacy bundle’s Maven module definition.
com.microsoft.copilot.eclipse.ui.terminal.tm/OSGI-INF/component.xml	Removes DS component definition for legacy bundle.
com.microsoft.copilot.eclipse.ui.terminal.tm/META-INF/MANIFEST.MF	Removes OSGi manifest for legacy bundle.
com.microsoft.copilot.eclipse.ui.terminal.tm/build.properties	Removes PDE build properties for legacy bundle.
com.microsoft.copilot.eclipse.ui.terminal.tm/.settings/org.eclipse.m2e.core.prefs	Removes legacy module m2e settings.
com.microsoft.copilot.eclipse.ui.terminal.tm/.settings/org.eclipse.jdt.core.prefs	Removes legacy module Java compiler settings.
com.microsoft.copilot.eclipse.ui.terminal.tm/.project	Removes legacy Eclipse project metadata.
com.microsoft.copilot.eclipse.ui.terminal.tm/.classpath	Removes legacy module classpath metadata.
com.microsoft.copilot.eclipse.ui.terminal.tm/.checkstyle	Removes legacy module Checkstyle metadata.
com.microsoft.copilot.eclipse.ui.jobs/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.ui.jobs/build.properties	Unifies output folder to target/classes/.
com.microsoft.copilot.eclipse.ui.jobs/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21 (and forbiddenReference severity).
com.microsoft.copilot.eclipse.ui.jobs/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.ui.jobs/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.terminal.api/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.terminal.api/build.properties	Unifies output folder to target/classes/.
com.microsoft.copilot.eclipse.terminal.api/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.terminal.api/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.terminal.api/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.swtbot.test/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.swtbot.test/build.properties	Normalizes source/output folder entries.
com.microsoft.copilot.eclipse.swtbot.test/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.swtbot.test/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.swtbot.test/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.core/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21 (and touches exported package metadata).
com.microsoft.copilot.eclipse.core/build.properties	Normalizes source/output folder entries.
com.microsoft.copilot.eclipse.core/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21 and related codegen/debug prefs.
com.microsoft.copilot.eclipse.core/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.core/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.core.test/META-INF/MANIFEST.MF	Bumps BREE to JavaSE-21.
com.microsoft.copilot.eclipse.core.test/build.properties	Normalizes source/output folder entries.
com.microsoft.copilot.eclipse.core.test/.settings/org.eclipse.jdt.core.prefs	Updates compiler settings to Java 21.
com.microsoft.copilot.eclipse.core.test/.settings/org.eclipse.core.resources.prefs	Sets project encoding to UTF-8.
com.microsoft.copilot.eclipse.core.test/.classpath	Updates JRE container to JavaSE-21 and marks it as modular.
com.microsoft.copilot.eclipse.core.agent.win32/META-INF/MANIFEST.MF	Bumps fragment BREE to JavaSE-21.
com.microsoft.copilot.eclipse.core.agent.macosx.x64/META-INF/MANIFEST.MF	Bumps fragment BREE to JavaSE-21.
com.microsoft.copilot.eclipse.core.agent.macosx.aarch64/META-INF/MANIFEST.MF	Bumps fragment BREE to JavaSE-21.
com.microsoft.copilot.eclipse.core.agent.linux.x64/META-INF/MANIFEST.MF	Bumps fragment BREE to JavaSE-21.
com.microsoft.copilot.eclipse.core.agent.linux.aarch64/META-INF/MANIFEST.MF	Bumps fragment BREE to JavaSE-21.
base.target	Removes the previous base target definition.
.github/workflows/ci.yml	Updates CI to use JDK 21.
.github/copilot-instructions.md	Updates repo instructions to reference the new target + Java 21 baseline.

[Dietrich Travkin (travkin79)]

I see, we also need to remove the obsolete dynamic loading of the terminal bundles. I'll continue with that tomorrow.

[Sheng Chen (jdneo)]

Wait, is removing the tm bundle a required step for this task?

[Andrey Loskutov (iloveeclipse)]

Wait, is removing the tm bundle a required step for this task?

Why is this a problem? Of course one can try to use old tm. terminal bundles with "modern" 4.38 Eclipse (I believe it would still work, but I didn't tried it), but what is the point doing so? Benefit is that we finally can get all the dependencies explicitly defined before installation, so the "modern" terminal bundles can be automatically installed along the Copilot plugin, and we don't need to have extra p2 code in Copilot which tries to installs the "right" terminal fragment on second startup.

[Dietrich Travkin (travkin79)]

Wait, is removing the tm bundle a required step for this task?

Hello Sheng Chen (@jdneo),
Short answer: No, removing the tm bundle is not a required step.

I thought, the terminal.tm bundle was only needed because of copilot's support for Eclipse versions below 4.37. If we move to the oldest supported Eclipse version 4.38 (2025-12), we no longer need that. So we can (don't have to) remove that obsolete bundle and also the complex terminal bundle loading mechanics that are no longer needed. That would make the code significantly less complex and even the target definition file does no longer need to be splitten into a common base.target plus two different target files for the different terminal bundles. The plug-in dependencies would become obvious and would simplify installation processes. Thus, I fully agree with Andrey Loskutov (@iloveeclipse).

I could also separate introducing the new target from removing the tm bundle in two different PRs if you like.

[Sheng Chen (jdneo)]

I tend to avoid removing the tm bundle at current stage, if it is not necessary.

There still quite a lot users using eclipse lower than 4.38, if we remove the tm bundle support, they will lose all the updates and fixes.

[Dietrich Travkin (travkin79)]

I tend to avoid removing the tm bundle at current stage, if it is not necessary.

There still quite a lot users using eclipse lower than 4.38, if we remove the tm bundle support, they will lose all the updates and fixes.

Hi Sheng Chen (@jdneo),
I adapted this PR accordingly.

In case you're interested in seeing how removing terminal.tm bundle and obsolete code for dynamically loading the terminal bundles would look like take a look at this branch: https://github.com/travkin79/copilot-for-eclipse/tree/drop-tm-bundle.

In this PR, terminal.tm bundle is built using 2024-12.target, but it seems, all tests (including those running in CI) are using 2025-12.target (similar to using target-terminal.target in main branch). If you want to explicitly test with multiple targets, you might want to adopt the multi-target approach from TM4E project.

[Andrey Loskutov (iloveeclipse)]

There still quite a lot users using eclipse lower than 4.38

Hmm. If 4.38 is in the target, how do you want to check compatibility with older releases? This would imply extra tests with older target platforms covering all used Eclipse API's are compatible with older versions.

Anyway, would it be easier to only require new versions of lsp4j/lsp4e, because AFAIK they can be changed/installed (almost) independently on used Eclipse SDK version.

[Sheng Chen (jdneo)]

Anyway, would it be easier to only require new versions of lsp4j/lsp4e

Ah, this is a good point. If we update the lsp4j required version, and if user wants to install the latest copilot plugin, they will be asked to update lsp4j, right?

And btw, what is the common practice here in eclipse community when a plugin wants to bump the target platform?

[Andrey Loskutov (iloveeclipse)]

If we update the lsp4j required version, and if user wants to install the latest copilot plugin, they will be asked to update lsp4j, right?

It depends. In your case this might fail, because the generated p2 Copilot update site (as of today) does not include dependencies, so if the end user does not have some update site which points to the updated lsp4j dependency, the installation will fail (AFAIK). This is the problem also for our users of our application: we don't add any update site to the application configuration on purpose, so that users don't get (possible not validated for compatibiluity) updates from any 3rd party libraries. Therefore we provide instructions how to update Copilot and provide offline update site which contains all reqired dependencies. I believe I even reported a ticket for exact this problem at very early days of Copilot :-)

From this point of view, to solve ths possible problem (especially for clients with "old" or "special" Eclipse platform), one could advise tycho to include all dependencies on the generated p2 update site. I'm not a p2 expert, but Copilot recmmended me following snippet for the pom file:

<plugin>
  <groupId>org.eclipse.tycho</groupId>
  <artifactId>tycho-p2-repository-plugin</artifactId>
  <version>${tycho.version}</version>
  <configuration>
    <includeAllDependencies>true</includeAllDependencies>
  </configuration>
</plugin>

This way, it doesn't matter which update sites users might or might not have in their Eclipse based applications, all dependencies specified by your target and required by Copilot should be there. Of course this will not include terminal bundles because they are not explicitly specified by any Copilot bundle which is on the update site - this dependency is "hidden" by the special after-the-install-install procedure in Copilot.

what is the common practice here in eclipse community when a plugin wants to bump the target platform?

Nothins special AFAIK. One can decide to bump the major or minor version segment depending on how severe the changes are, but it is not strictly required, except if the plugin provides some API which re-exports some of the dependencies which changed their API. In such case plugin minor (second) version segment should be updated, but Copilot bumps the minor segment anyway with every release.

[Dietrich Travkin (travkin79)]

Hi Sheng Chen (@jdneo) and Andrey Loskutov (@iloveeclipse),

Anyway, would it be easier to only require new versions of lsp4j/lsp4e

Ah, this is a good point. If we update the lsp4j required version, and if user wants to install the latest copilot plugin, they will be asked to update lsp4j, right?

I added a separate LSP4E update site to the target definition(s) in this PR. This way, it's easy to increase the required LSP4E version.

I'm not sure if we should use self-contained target definition files, e.g. 2025-12.target and 2024-12.target, or keep using a common base.target for common bundles. Self-contained files are easier to handle and it's easier to get rid of one of them (if we drop Eclipse 2024-12 support some day), but multiple self-contained target files have a few duplicated entries that need to be considered on each target file change.

In order to avoid installation issues with a missing LSP4E bundle version, I also added LSP4E and LSP4J bundles to copilot's own update site. Whatever LSP4E/LSP4J version copilot requires, it will provide it on its own update site.

From this point of view, to solve ths possible problem (especially for clients with "old" or "special" Eclipse platform), one could advise tycho to include all dependencies on the generated p2 update site. I'm not a p2 expert, but Copilot recmmended me following snippet for the pom file:

<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-p2-repository-plugin</artifactId>
 <version>${tycho.version}</version>
 <configuration>
   <includeAllDependencies>true</includeAllDependencies>
 </configuration>
</plugin>

I tried that, but with this option tycho puts way to many (Eclipse) bundles on copilot's update site. Instead, I added three selected LSP4E and LSP4J bundles to the category.xml in the repository project. It seems, we don't need to specify a certain version here -> no additional version maintenance effort needed. The versions seem to be taken from the target definition.

The MANIFEST.MF files require LSP4J version 0.21.1, but the target definition is set to 0.24.0 (the version offered in Eclipse 2025-12 which is now the minimum version for 2024-12 and 2025-12 targets). Should I increase the required versions in the MANIFEST.MF files to be consistent? Or do you want to update the LSP4E/LSP4J versions to the latest or some other version (maybe in a separate PR/commit), Sheng Chen (@jdneo)?

[Andrey Loskutov (iloveeclipse)]

I tried that, but with this option tycho puts way to many (Eclipse) bundles on copilot's update site. Instead, I added three selected LSP4E and LSP4J bundles to the category.xml in the repository project. It seems, we don't need to specify a certain version here -> no additional version maintenance effort needed. The versions seem to be taken from the target definition.

Great idea.

[Dietrich Travkin (travkin79)]

Hello Sheng Chen (@jdneo),
Do you plan to review and merge this PR some time soon?

[Sheng Chen (jdneo)]

What about 4.37? Why that version is not in either of the two ranges?

[Dietrich Travkin (travkin79)]

Hello Sheng Chen (@jdneo),
That's an important question. I didn't realize, I created a version gap. I created the PR some time ago, so I re-checked our conversations and my commits to find out, how that happened and what we originally wanted.

• Originally, you said, you wanted to bump the version to 2025-12 (4.38)
• I interpreted that as "2025-12 (4.38) will become the oldest supported Eclipse version, we'll support version >= 2025-12 (4.38)" and created in this PR only one target file for 2025-12.
• You pointed out that you prefer not removing support for terminal.tm.
• I thought, we need a second target file with the Eclipse version still using terminal.tm and used the Eclipse version from target-tm-terminal.target (and assumed, newer Eclipse versions would not offer terminal.tm bundles).

This way, it seems, I unintentionally created that version gap. In fact, the target files were never made to cover version ranges. They are built for exactly one target platform (Eclipse IDE and plug-ins version). I fixed the wording here. Nevertheless, I re-checked the versions used in Copilot for Eclipse and in this PR.

Originally, Copilot for Eclipse documented a boundary at

• modern terminal: >= 2025-09 (4.37)
• TM terminal: < 2025-09 (4.37)

Eclipse releases > 2025-06 (4.36) no longer publish the tm.terminal.* bundles that Copilot's terminal.tm plug-in needs — confusingly, even 2026-06 (4.40) still ships tm.terminal bundles, but only tm.terminal.connector.* (see also #368 (comment)).

Things to consider:

• The terminal bundle loading mechanism in Copilot for Eclipse (TerminalServiceManager) decides at runtime, which terminal bundles to use, i.e. Eclipse >= 2025-09 (4.37) leads to using modern terminal bundles, < 2025-09 (4.37) leads to using TM terminal bundles.
• Today, CI only tests against exactly one Eclipse version (2025-03 (4.35) from base.target). Testing multiple targets would require a target matrix in the workflow file similar to TM4E. This PR would raise the tested baseline to 4.38, testing modern terminal instead of TM terminal.

Since according to Sheng Chen (@jdneo) there are still many users having Eclipse < 2025-12 (4.38), I suggest to leave the mechanism in TerminalServiceManager unchanged and use at least two target files, one for 2025-12 (4.38) with the modern terminal (covering the >= 2025-09 (4.37) case) and one for 2024-12 (4.34) with the TM terminal (covering the < 2025-09 (4.37) case).

If someone wants to explicitly test / compile against 2025-09 (4.37), we'd have to introduce a third target file for that version using the modern terminal.

In a separate PR, we could also introduce a target matrix in the workflow file similar to TM4E to also run tests using the TM terminal.

[Andrey Loskutov (iloveeclipse)]

it turns out that even the latest release 2026-06 (4.40) still offers the terminal.tm bundles.

Could you please post a link to the update site you've used? It must contain some aggregation links to older platform?

[Dietrich Travkin (travkin79)]

I checked https://download.eclipse.org/releases/2026-06/ using the Repository Explorer in Eclipse IDE.

I looked more closely and I see, versions > 2025-09 (4.37) do offer tm.terminal bundles, but not the ones required by copilot's terminal.tm plug-in. Only tm.terminal.connector.* bundles are offered in newer Eclipse versions / update sites.

But it seems, not 2025-06 (4.36) is the latest version offering the TM terminal bundles, but 2025-09 (4.37), see https://download.eclipse.org/releases/2025-09.

[Andrey Loskutov (iloveeclipse)]

Note, what you see there are not the "core" terminal bundles but CDT extensions, which didn't changes namespace but should be consumed by the new platform terminal.

(new) Platform core terminal bundles:

org.eclipse.terminal.feature
org.eclipse.terminal.connector.local
org.eclipse.terminal.connector.process
org.eclipse.terminal.connector.ssh
org.eclipse.terminal.connector.telnet
org.eclipse.terminal.control
org.eclipse.terminal.view.core
org.eclipse.terminal.view.ui

CDT extension of terminal bundles:

org.eclipse.tm.terminal.connector.cdtserial
org.eclipse.tm.terminal.connector.remote

[Dietrich Travkin (travkin79)]

Thank you for that clarification Andrey Loskutov (@iloveeclipse).

[Dietrich Travkin (travkin79)]

I fixed the wording in CONTRIBUTING.md and rebased my commits on the main branch.

[Sheng Chen (jdneo)]

Overall LGTM. Just one thing I'm worrying is about how customer will react about the fact that they need jdk 21 for the plugin. That's a breaking change. And not sure for some enterprise users, jdk 21 is even available or not on their side.

[Andrey Loskutov (iloveeclipse)]

I'm all for avoiding breaking compatibility changes, but... With the IDE/AI world changing so fast, I wonder how one could still want to run IDE on Java 17 released 5 years ago and platform released 2 years ago. I can imagine that for production / backend one still want use Java 17 or even 8, but not being able to update runtime for the IDE seem to be a clear execution failure. AFAIK VS Code provides weekly platform updates, we are talking here about being years behind.

At the end, keeping platform at very old Java / Eclipse builds prevents Copilot to move forward and wastes time supporting outdated platform, so at the end everyone will loose, including these customers with Java 17.

[Dietrich Travkin (travkin79)]

Hi Sheng Chen (@jdneo),
I understand your concerns. But Andrey Loskutov (@iloveeclipse) has good arguments for moving forward, for using Java 21. In addition, if some company cannot install Java 21 for their IDEs, they could keep using the last JRE-17-compatible copilot for eclipse version, right?

I saw, the CI build did not finish successfully. I think, I fixed it now, but I guess, someone needs to explicitly trigger the CI build again. It turns out, I forgot to update to bundles to JavaSE-21.

[Sheng Chen (jdneo)]

Dietrich Travkin (@travkin79)

What about we do the transition in a more smooth way. For example:

1. We first add an announcement in the IDE plugin(release notes and a possible popup notification) and repo's readme, saying that we will stop support <4.36 Eclipse start from, let's say 0.23.0 (Now is 0.21.0, next version is 0.22.0, so we have one version's time window)
2. Then we totally make a clean migration, including bump jdk requirement to 21 and remove tm terminal support. in 0.23.0

WDYT?

[Dietrich Travkin (travkin79)]

Hello Sheng Chen (@jdneo),

Announcing the breaking change before actually releasing it sounds like a good approach from a users' point of view. I like the second point very much, i.e. cleaning up code and getting rid of tm terminal and the now no longer needed custom loading mechanism.

The only thing I'm not sure about is how many users we have that are still needing the old Eclipse and tm terminal compatibility. If there are only a few, announcing the change and delaying it may be not worth the effort.

Andrey Loskutov (@iloveeclipse), any thoughts on that?

[Andrey Loskutov (iloveeclipse)]

any thoughts on that?

We've discussed that with Sheng on teams and I agree with the last proposal.

[Dietrich Travkin (travkin79)]

Hi Sheng Chen (@jdneo),
I had to fix another test issue. Could you trigger the CI build run again?

1. We first add an announcement in the IDE plugin(release notes and a possible popup notification) and repo's readme, saying that we will stop support <4.36 Eclipse start from, let's say 0.23.0 (Now is 0.21.0, next version is 0.22.0, so we have one version's time window)
2. Then we totally make a clean migration, including bump jdk requirement to 21 and remove tm terminal support. in 0.23.0

Would you take care of the first point, Sheng Chen (@jdneo)? I would add tm terminal removal to this PR (and rebase), so that it will be ready for version 0.22.0.

[Dietrich Travkin (travkin79)]

Hello Sheng Chen (@jdneo),

... I would add tm terminal removal to this PR (and rebase), so that it will be ready for version 0.22.0.

I rebased the commits from this PR on the main branch. I created a separate PR #471 with the obsolete terminal.tm plug-in and the dynamic terminal bundle loading removed. I think, creating a separate PR makes the review easier.

Today, PR #471 includes all commits from this PR plus additional commits for the removal. For that reason I left it as a draft PR for now, as long as this PR is not merged.