Include copilot in packages

[merks]

With copilot becoming an Eclipse project

• https://projects.eclipse.org/projects/tools.copilot
• https://github.com/eclipse-copilot

and with the project's intent to join SimRel:

• https://www.eclipse.org/lists/simrel-dev/msg00070.html

should we plan to include copilot in one or more, or even all, packages?

Please share you thoughts.

[akurtakov]

There was some extra note to be added to each package that includes "incubating" plugins. I don't remember the details but I'm bringing it here in case someone remembers.

[merks]

I believe all packages already contain incubating components if I recall correctly per the instructions we follow for each m*/rc* so I think this is of negligible concern currently.

Specifically this line documents that tm4e is in all packages and is incubating:

packages/RELEASING.md

Line 52 in 9b7e023

- This item is not currently done per milestone/release because for a while now all packages contain incubating components and until TM4E moves out of incubation this step is redundant.

[merks]

I really need some opinions and feedback here.

Below are some experiments I did to capture a bit more detail.

---

I modified the setup model such that a PGP-signed version of copilot is installed along with the each current staging repository package. I used this site.

https://download.eclipse.org/oomph/copilot/nightly/latest

See eclipse-simrel/simrel.build#974 (comment) for discussions about the pending SimRel contribution for copilot.

I installed the JEE package. (Of course you can install copilot manually into any package yourself).

When the IDE starts, this modal dialog is immediately presented to the user.

There are discussions about that dialog here:

eclipse-copilot/eclipse-copilot#23

It covers the dialog that prompts for excluding the installation from virus scanning, and it cannot be resized or moved.

Clicking Start using Copilot closes the intro page, opens an editor on HTML release notes for copilot, shows the chat view, and we can see the dialog for disabling defender that was previously covered:

Note the Copilot menu bar item to the right of the Help as well as the Copilot status icon on the bottom right (both circled in red above). They both appear to provide the same menu content.

Unfortunately I'm not sure how to reproduce a completely new user experience where you need to register; I did that once and it seems to remember somewhere.

If you open a new workspace with the same IDE, the "Start using Copilot" dialog comes up again. If you close the dialog, restarting the workspace does not prompt again. The contributions are still present in that case:

But the chat isn't opened. If I open a new perspective, the chat view is there in many of the perspectives even in a workspace where I did not choose to start using copilot.

There are two terminal views:

---

The helpful answers are really impressive!

---

The core bundle has a seriously large footprint of almost 140MB. This could be reduced by factoring out the agents/distros into fragments:

eclipse-copilot/eclipse-copilot#17

Only 4 platforms (of the 7 supported by EPP) are currently supported by built-in agents; see the discussion above.

The agents are fetched via npn in this folder before the plugin is built:

https://github.com/eclipse-copilot/eclipse-copilot/tree/main/org.eclipse.copilot.core/copilot-agent

[jonahgraham]

should we plan to include copilot in one or more, or even all, packages?

My general feeling is if some of the UX stuff can be addressed (particularly eclipse-copilot/eclipse-copilot#23 + duplicate terminals + install size*) then it can be included. I think it should be in all packages.

* I don't know how much the install size really matters.

[jonahgraham]

Only 4 platforms (of the 7 supported by EPP) are currently supported by built-in agents; see the discussion above.

IIUC based on the answers provided in eclipse-copilot/eclipse-copilot#17 all platforms are supported, some just need a node installed and use the WASM version instead of the native version.

Some packages already include a node install, so don't need to use the system node.

[HannesWell]

It it's great that a Eclipse-native Copilot integration is about to be available, many people have waited for that and will probably be very happy about it. On the other hand, those that don't want to use it will probably not be happy about it, at least in the current form and behavior.
I also did what Ed summarized and I can confirm that the Copilot integration is really dominant right from the start-up. If one wants to use Copilot, that certainly helpful but those that don't want to use it, are probably heavily annoyed by that behavior.
I'm not aware of any Plug-in in the SimRel that behaves like that.

In general this Plug-in also gives up some of Eclipse full openness as it only works if one sign's in into a propitiatory service. It's clear why this is necessary, but it's still new for Eclipse (AFAIK). I can only remember that Oomph used to have the ability to share setups across devices, which also required a login, but that's gone and was an EF service, not one from a third-party company and didn't suggest to purchase a payed subscription.
For sure we cannot change that, but for me that would be a reason to make it not as prominent as it's at the moment.

The core bundle has a seriously large footprint of almost 140MB. This could be reduced by factoring out the agents/distros into fragments

That will probably become by far the largest bundle in the entire SimRel. The largest one I'm aware of is currently org.eclipse.platform.doc.isv with 42MB. And given that the current packages range from 350MB to 650MB, adding another 140MB is definitively significant.

• I don't know how much the install size really matters.

Of course it's often downloaded quickly. But if all users download it, it really sums up. And given that Green-IT is also a topic and the IT-team even asks us to reduce writes in builds and avoid unnecessary builds to reduce load on the infrastructure or to clean-up download areas. E.g. for SWT the fragments are much smaller and still we put a lot of effort into separating it and keeping them small. Adding such a large bundle where most of the content is never needed because it's for a different arch (or a user just doesn't want to use it), takes all these efforts to absurdity.

To make a long story short, in my opinion and with the current state, it could be more suitable to just advertise this new Feature prominently, e.g. using the new Oomph notification framework that Ed implemented recently, to make it trivial to get it for those that want to use it and easy to dismiss for those that don't want it. It might even be interesting to add an Install always option, which adds a requirement to the Copilot Feature to the User setup and will consequently be installed in all installations of a local users.
This should hopefully make and keep everybody happy. :)
But that's my opinion, in the end the package maintainers have to decide that.

[eselmeister]

Using Copilot and other AI tools is basically fine, but I have strong concerns to include it by default. For me, it's unclear what data is transferred to the Microsoft Copilot server. This is IMHO not clear yet.

When running Copilot on source code, which is already open source, then it's not a big thing.
But when running on proprietary code, it might be a serious issue if data is transferred to a Microsoft server in an unintended way. It would be less optimal if proprietary source code is released by incident due to a security issue or somewhat while using Copilot.

That's why I vote against the plan to include Copilot in the SimRel.
If users want to have, they should do it on purpose.

[opcoach]

Using Copilot is nice but sometime intrusive..

I use Eclipse for java dev, and visual studio or Theia for php dev (for my web sites)... and the chatgpt standalone application on my Mac. So I can mix all my AI questions in the chat gpt application which knows my GLOBAL context and not only about the code. This is interesting to have answers including information that was not necessary in the code. For this reason I would prefer to have an optional install.

The ChatGPT application (on Mac and I suppose also on windows) can detect what are the current tabs opened in other application and it adds the content in its context. I have seen it working with the terminal, visual studio, but neither with theiai nor with eclipse. I opened a bug on theiai ai about it (see here : eclipse-theia/theia-ide#529)

So I would prefer to have a mixed solution that will solve all these questions: the copilot menu and button in status bar should be always visible, but copilot would not be installed yet. And if we need it, the menu propose to install it. This would show that it is available but installed only on request. Actually we should deliver a kind of 'copilot proxy' that would always be in simrel. And this will solve the problem of download size and meet the green concerns. May be that could be an additional new feature in the copilot project and this feature will be pulled for the release.

[waynebeaton]

I had assumed that respecting the Eclipse UI Guidelines was a requirement for participation in the simultaneous release. By my interpretation of the guidelines, that the menu has been added to the menu bar at all is sketchy, but the placement is clearly in contravention of the guidelines. I have memory scars (but can't quite remember the horrifying name that Ed gave it) from looking at the result of installing everything in the simultaneous release.

If we have concerns about the user experience that the project is providing, we really should engage directly with the Eclipse Plug-in for Copilot team on their issue tracker.

I will create an issue to ask for clarification regarding data that they're capturing. FWIW, having an Eclipse open source project send usage data to a single vendor is offside. Any data that their product collects (after the user expressly consents to using that product) is their business.

[opcoach]

It seems to be the discussion like 20 years ago : I want to be the default navigator on this OS. And then you must ask the user : this navigator X is not the default, would you like to use Y instead ? Really boring and not productive.

In fact, if Copilot is delivered by default that will make other AI difficult to be included in Eclipse. And all contributors will give up with AI. I would prefer an official Eclipse "AI" Menu provided by the platform and a new extension point to declare the AI we want to use/install... It could also provide options like : download a local model (like ollama does), or download dan integrated distribution (like copilot)...

This would be not intrusive and will make contribution interesting to do for new contributors. Theia AI can use any kind of AI, why Eclipse could not ?

[tjwatson]

This would be not intrusive and will make contribution interesting to do for new contributors. Theia AI can use any kind of AI, why Eclipse could not ?

I think this is an extremely important point and one that I think should prohibit us from including co-pilot by default in any of the Eclipse packages. The Eclipse packages should not default to a particular AI at this time. Co-pilot installation should be an explicit decision by the Eclipse user in my opinion.

Besides any usability concerns with co-pilot this is far and above the most important concern to me.

[mpalat]

I think this is an extremely important point and one that I think should prohibit us from including co-pilot by default in any of the Eclipse packages. The Eclipse packages should not default to a particular AI at this time. Co-pilot installation should be an explicit decision by the Eclipse user in my opinion.

Resonating with @tjwatson on this. From a general perspective, I would like Eclipse packages not to have co-pilot or any other AI tool by default. From a company's point of view, in which this company Y has a similar product, an already available AI based tool by default would be an unfair disadvantage (essentially echoing @opcoach's point here.

Essentially a "NO" to co-pilot by default.

[iloveeclipse]

in my opinion and with the current state, it could be more suitable to just advertise this new Feature prominently, e.g. using the new Oomph notification framework that Ed implemented recently, to make it trivial to get it for those that want to use it and easy to dismiss for those that don't want it. It might even be interesting to add an Install always option, which adds a requirement to the Copilot Feature to the User setup and will consequently be installed in all installations of a local users.

I've checked VSCode (note: I'm not VSCode user, so might be I've overlooked something): it advertises Copilot on the web page but it seems that the default distribution doesn't include it automatically, it can be installed from the "recommended" extensions list.

So why isn't possible to do the same:

1. Advertise the Copilot plugin on Eclipse IDE landing page.
2. Advertise it (with link) on the "Welcome page" and/or if IDE installed via Oomph, use "Notifications" to highlight the plugin.
3. Do not include it in the existing binary packages yet.
4. Eventually (depending on the code state) create dedicated AI-enabled package with Copilot if it will be open source project at Eclipse.org. If we have a dedicated "Eclipse IDE for Scout Developers" package with some ~3.000 downloads, why can't we have "Eclipse IDE with AI for Java Developers" package that would for example include all what Eclipse IDE for Java Developers has plus Copilot & Terminal? We will see how many people would download that package, and I bet the numbers will be higher as for many other packages we provide. Copilot team & Microsoft could maintain the package in the future.

@waynebeaton, @jdneo: Wouldn't that match what Microsoft own solution does and satisfy both Microsoft & Eclipse Foundation?

I feel it sad that there are lot of interest in AI solutions from Eclipse but we are stuck at the discussion here.

[merks]

Yes, I too feel very sad and really disappointed. I have proposed and prototyped what you are suggesting, here with the really pretty graphics from the Microsoft team cut off on the right because I don't know the license/copyright for those graphics:

I think it looks really compelling. It works just like this one for JDT's Java 25 patch which will be available with Java 25 releases shortly:

eclipse-jdt/eclipse.jdt.core#3822 (comment)

For Copilot I've even configured the notification to maximize the view so that you can't miss it. Installing is so easy a child could do it...

I've even suggested that we can do this at any time when Copilot is ready to be installed in existing 2025-09 packages, hoping that folks will work towards a release as soon as possible. E.g., we could roll this out in September if the ball keeps rolling forward. We don't need to wait for December which is a slow time...

---

We've really not gotten as far as taking about new packages, which to me mostly sounds like yet more work, longer builds, bigger footprints, and so on. Moreover it's hard to imagine that a large fraction of the community of each package will not want it in their favorite package and would prefer not having to choose one "special" package (which they will never see when updating).

I'm also pretty frustrated about all this because the conversations that we should have in the community are instead bubbling up to Eclipse Foundation staff and/or are happening outside the community. This talk of a special Copilot package seems completely premature and smacks a little bit as a way to bypass the conversations that we should be having. What problem we are solving by taking that approach?

There are some things that simply have not been made clear to me and I have asked for clarification. Most importantly: No one has made it clear to me why there is this unrelenting, single-minded focus on being pre-installed in all/an EPP package. What's with that? Please someone explain this to me. That may well come in due course, but it's somehow become a prerequisite for Copilot being an Eclipse project, which is questionable twist of events. Copilot has not even released yet...

I know for a fact that there are many people interested in working towards the goal of AI integration. But somehow the conversations are not happening and I feel like a stream roller is coming straight at me. So I'm actually a little bit past the point of frustration. This is not how things should work. If we worked better together, we could achieve something really cool...