eclipse.tm.terminal > eclipse.terminal rename with next Eclipse platform / CDT releases

[iloveeclipse]

Note, the dependencies of the copilot (and the code involved) will have trouble after the org.eclipse.tm.terminal is moved from CDT into Eclipse platform (with Eclipse 4.37 / CDT 12. ... something).

The terminal view and connectors are moved to Eclipse Platform from CDT and will be not included in the next CDT version, if I understand it right. This wouldn't be a big issue, but all API/non-API/namespaces are changed.

See

• Migrate org.eclipse.tm.terminal.view.core eclipse-platform/eclipse.platform#1965
• Migrate org.eclipse.tm.terminal.view.ui eclipse-platform/eclipse.platform#1966
• Migrate org.eclipse.tm.terminal.connector.process eclipse-platform/eclipse.platform#1970
• Migrate org.eclipse.tm.terminal.connector.local eclipse-platform/eclipse.platform#1973
• Rename eclipse.tm.terminal > eclipse.terminal eclipse-platform/eclipse.platform#1979
• Make provisional terminal control API public eclipse-platform/eclipse.platform#1995

and many other related PR's.

So either there will be need to create two different Copilot releases (for "old" eclipse.tm.terminal and "new" eclipse.terminal) or the Copilot will rely on older CDT (not sure how that would work in installations that would require both latest CDT and Copilot that would require parts of old CDT).

FYI: @jonahgraham, @laeubi, @jdneo

[laeubi]

Technically as both things use a different namespace a plugin that wants to integrate could have extensions/code for both the old and the new one (e.g. using optional import package) and one of them is then simply not picked up. The build then of course need to contain both versions...

Beside that I always wondered why people like to use latest A with older B in the same installation where A + B are dependent components... so it seams also fine to me for a latest Copilote-Eclipse-Plugin to require latest Eclipse + latest CDT ... of course everything depends on how copilote-eclipse uses these components... maybe the copilote plugin could suggest a solution here ;-)

[iloveeclipse]

Beside that I always wondered why people like to use latest A with older B

Because people want to provide plugins also for older SDK versions. Not everyone can simply use latest SDK, and it is obvious that there are more users that use older SDK versions at the release point of the latest SDK.

In this case we have first official Copilot plugin release coming. Why shouldn't people with Eclipse 4.36 (or slightly older) be able to use that, why should they be forced to update SDK and CDT and whatever else? As a private person sure one can use whatever version, but there are developers in companies with specific environment restrictions, Eclipse based products that have their own boundaries etc.

Technically as both things use a different namespace a plugin that wants to integrate could have extensions/code for both the old and the new one (e.g. using optional import package) and one of them is then simply not picked up.

The question for me is: let assume this is not done for some reason (I don't have code access, so no idea how much of Copilot code is bound to the old CDT terminal code), would the current state work with all the SDK / CDT dependencies chains combined in one installation? It would be enough if a single dependency would be a singleton or something like that. This must be understood and evaluated.

Also it would most likely double all UI contributions related to Terminal view and connectors.

The point here in this ticket is to make Copilot developers be aware about upcoming troubles, and involve platform & CDT responsible developers to a ln early validation of what the namespace changes of the "terminal" related bundles would mean for the downstream projects & users.

[jdneo]

@iloveeclipse Thank you for bringing this up.

Personally I don't want to create two different Copilot releases, which may confuse users which one should be installed.

Would like to hear @jonahgraham for suggestions.

[laeubi]

The question for me is: let assume this is not done for some reason (I don't have code access, so no idea how much of Copilot code is bound to the old CDT terminal code), would the current state work with all the SDK / CDT dependencies chains combined in one installation?

You can try to install "new" terminal plugins into whatever "old" installation you are concerned about and then we might lower version ranges (if suitable), then you have two UIs that do the same (as there are two namespace you can install everything in parallel).

Anyways I think the more usual case would be that I either have the new set of plugins or the old (I don't see any benefit installing both) ... but this depends on how copilote uses that code, how it integrates, what its requirements and so on and we don't know as you correctly mentioned as its closed source... but everything is doable if one wants to invest the time / efforts into this.

Also note that everything was only ever provisional API means can change any time and should be only used in close coordination with the provider of that API (not sure if CDT team was involved here in any way).

[iloveeclipse]

I'm asking what is actually the reason to use Terminal in Copilot, if the "only" use case is to start a command, read the output and show something to the user. Custom IOConsole can achieve that do that in every Eclipse version without entering dependency hell. I guess refactoring code to use different Terminal namespaces is more complicated as refactoring to use custom IOConsole.

[laeubi]

By the way I checked the copilote feature and it only requires its own bundles --> good!

<required namespace='org.eclipse.equinox.p2.iu' name='com.microsoft.copilot.eclipse.core' range='[0.8.0.202506180627,0.8.0.202506180627]'/>
<required namespace='org.eclipse.equinox.p2.iu' name='com.microsoft.copilot.eclipse.ui' range='[0.8.0.202506180627,0.8.0.202506180627]'/>

checking further, only the UI require the terminal by require bundle, so if one wants to download that stuff and check plugin.xml for reference we would know if it extends anything there (e.g. connector, new commands, what else) and check the classfiles for references so we know what API actually is accessed.

I guess refactoring code to use different Terminal namespaces is more complicated as refactoring to use custom IOConsole.

The Eclipse IOConsole is just to limited for most commandline utilities, this will change in newer Eclipse, see

• Add support for launching Eclipse Process in a system terminal session eclipse-platform/eclipse.platform#1762
• Add support for open a Terminal in the Console View eclipse-platform/eclipse.platform#1969

If one only wants to start a command and read the output (without interaction to the user), one do not need a console at all.

[jdneo]

There are couple of reasons why using the integrated terminal.

The major one is that users can interact with terminal, for example. type ctrl + c to kill it.

Some other benefits are:

• Better output rendering
• execution history navigation

The Eclipse IOConsole is just to limited for most commandline utilities, this will change in newer Eclipse
what does this mean? is the terminal launched in console view different from ones launched in terminal view?

[iloveeclipse]

The Eclipse IOConsole is just to limited for most commandline utilities, this will change in newer Eclipse
what does this mean? is the terminal launched in console view different from ones launched in terminal view?

These are just two different implementations of providing a "console". Terminal aim is to mimic the real system console with more features, while IOConsole is a generic console implementation that can be used to provide interactive IO console. IOConsole is "good enough" to start any process via command line and get all the output of the process / check the process status / control the process life cycle. It doesn't provide the command line history, but that (along with any other features) can be added on top if needed.

for example. type ctrl + c to kill it.

Well, every console can be closed & process terminated, the "Ctrl+C" is of course unfortunate (it is used to "copy" console text), but is that really a "must have" feature? Custom shortcuts are of course possible, along with Ctrl+C redefinition.

The one issue with the Terminal now (as far as I understood it from other tickets), there is no reliable way to listen to the process state or output and the second one is the namespace change that will happen just now in the upcoming SDK / CDT releases.

[laeubi]

@jdneo can you please make a search for org.eclipse.tm.terminal in the source and just let us know what classes or files referenced by the plugin? That would help to better give advice for possible mitigations!

what does this mean? is the terminal launched in console view different from ones launched in terminal view?

The main reason for integrating this into platform was is just integrated into the usual Eclipse Eco-System while the previous terminal view was always just an addition to an existing project.

So now it does not require the Terminal View and allows to directly launch a command inside a terminal session see here for a demo. Further details can be found here.

As I don't use copilote or the plugin I can't tell if it would be an alternative or even more suitable here and how copilote currently integrates / use the cdt terminal.

[laeubi]

It doesn't provide the command line history, but that (along with any other features) can be added on top if needed

This is only part of the truth (beside that it simply never was implemented), some processes need to function a Pseudoterminal, and you need a VT100 or similar emulation on the UI side, both things are not trivial to implement in the current TextViewer Model based IO Console as it has a more linear view of the output. We already added ANSI coloring, but even that takes a long time to integrate and there are still some pitfalls (e.g. copy). Then the current input method is based on reading lines, not characters and so on.

The one issue with the Terminal now (as far as I understood it from other tickets), there is no reliable way to listen to the process state or output and the second one is the namespace change that will happen just now in the upcoming SDK / CDT releases.

I think there is a miss understanding here. What is referred as "Terminal" here is actually a shell (e.g. /bin/bash on linux) process executed and in this process you can execute other commands. So technically the process never ends (always running) and one would need to watch the child processes (what would likely require native access function) and pipe their output (again this might include terminal commands that need to be understood!).

In contrast, if you start a new Process using the Spawner (and just display the result in a Terminal Control) you are in full control of the process state and its input and outputs. This part has not changed and Platform is just using the API from CDT here.

And that what the new org.eclipse.debug.terminal does, it provides the same infrastructure as we have with the launch configs today and its API to watch process execution and access the streams, but inside a PTY and rendering the results in a VT100 like emulator.

By the way what probably would work is executing an own (native) process (even a java one) using the Spawner and then fire up own commands then you always know the Process and can fully control it. Of course then one has to emulate what bash does and how to communicate with the hosting Eclipse...

[jdneo]

can you please make a search for org.eclipse.tm.terminal in the source and just let us know what classes or files referenced by the plugin

[jdneo]

BTW, for now, I think the first priority is to find a least cost way to fulfill the compatibility issue. And meanwhile we can continue discussing whether to use IOConsole or sth else to replace the terminal, which can be another discussion thread?

[laeubi]

@jdneo It seems only one class is actually affected here (RunInTerminalTool), of course its hard to guess without the Code for the impact, but maybe using reflection would be an option here? Maybe it would be possible to extract that code into an own bundle and access it using a service interface? Then it should be possible to have two variants of that bundle (one for old one for new) an users can install what is suitable for their install.

There are other option possible but it all depends on the structure of the code.

Apart from that I would investigate the following:

• Check references to UIPlugin you should actually never need to access this (internal) class
• IUIConstants only holds one string, you should inline it so you have no dependency to that
• Check your usage of IPreferenceKeys one should really not mess around with other plugins preferences! You maybe want to inline these as well

If you look at org.eclipse.terminal.view.core.TerminalServiceFactory it already uses some kind of reflection to get a class by name from a bundle by name. This would be something you can do in your code directly and as an entry point to decide what bundle is available.

If that then returns an Object from that on you might be able to complete transparently handle it.

[jdneo]

If you look at org.eclipse.terminal.view.core.TerminalServiceFactory it already uses some kind of reflection to get a class by name from a bundle by name. This would be something you can do in your code directly and as an entry point to decide what bundle is available

I think so, thank you!

Check references to UIPlugin

It's used to get the args for the shell String args = UIPlugin.getScopedPreferences().getString(IPreferenceKeys.PREF_LOCAL_TERMINAL_DEFAULT_SHELL_UNIX_ARGS);

If it's empty, we will add -l to the process args to make sure a login shell is launched.

[jdneo]

One more question: Does that mean the copilot plugin needs to declare both new and old terminal bundle as optional required bundle?