Missing dependencies in version 0.11 · Issue #26 · microsoft/copilot-eclipse-feedback · GitHub
Skip to content
This repository was archived by the owner on Apr 28, 2026. It is now read-only.
This repository was archived by the owner on Apr 28, 2026. It is now read-only.

Missing dependencies in version 0.11 #26

Closed
Closed
Missing dependencies in version 0.11#26

Description

@HHartvig
Henrik Hartvig Jensen (HHartvig)
opened on Sep 1, 2025

When installing version 0.11 into Eclipse, not all required dependencies are handled. This allows me to install the plugin with this requirements being checked. And then I end up in this situation after restart, where one of the plugins tries to start the required bundles.

Image

One solution could be to add the requirements from the two packaged jars to the required bundles of com.microsoft.copilot.eclipse.ui, that should resolve the problem I guess.

Image

Let me know if this can be tried out in one of the nightly builds.

Activity

  1. iloveeclipse commented on Sep 1, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 1, 2025

    Same as eclipse-copilot/eclipse-copilot#41 (comment)...

  2. jdneo commented on Sep 10, 2025

    @jdneo
    Sheng Chen (jdneo)
    on Sep 10, 2025
    Member

    Andrey Loskutov (@iloveeclipse)

    I can summarize the current implementation here.

    The project structure looks like this

    • core
    • ui
    • terminal.api (the abstraction layer)
    • terminal (implementation of the run_in_terminal tool based on the new eclipse.terminal)
    • terminal.tm (implementation of the run_in_terminal tool based on the old eclipse.tm.terminal)

    terminal and terminal.tm are built first, and the output jars are treated as resources.

    When the copilot plugin activated, it check the eclipse version and install related terminal bundle to OSGi accordingly.

    I guess the problem is that directly install the bundle will not install the required dependencies.

    Do you have any idea how we can solve this?

  3. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    Ed Merks (@merks) , Christoph Läubrich (@laeubi) : please correct me if I'm wrong, you have much more knowledge in p2/installation area.

    What I see is that none of the copilot bundles (except "hidden" terminal and terminal.tm bundles) has any dependency to any eclipse.tm.terminal or eclipse.terminal bundles. The both "hidden" copilot terminal bundles with direct dependencies to eclipse.tm.terminal or eclipse.terminal bundles are not required in any way by other copilot bundles or features because they are installed not by p2 but by copilot itself after installation / restart.

    So during initial installation, if user does not explicitly select any of eclipse.tm.terminal or eclipse.terminal features for installation, copilot feature will be happily installed but on next startup an error will be reported because the platform doesn't contain any of eclipse.tm.terminal or eclipse.terminal bundles.

    So one need some kind of a "link" from Copilot feature to one or other eclipse.tm.terminal or eclipse.terminal features.
    This link can't be mandatory for both features, as it would force users to install duplicated terminal functionality with different names. I'm not aware about possibility to specify mandatory either or requirement for installation. If there is one, we are fine.

    Assuming there is no way to specify mandatory either or requirement during installation of a feature, what about providing two Copilot features on same update site, like "Copilot with modern terminal support" and "Copilot with legecy terminal support" ?

    "Modern" Copilot feature would include terminal bundle and require eclipse.terminal feature, "legacy" Copilot feature would include terminal.tm bundle and require eclipse.tm.terminal feature.

    I believe this should work. WDYT?

  4. merks commented on Sep 10, 2025

    @merks
    Ed Merks (merks)
    on Sep 10, 2025

    Could you remind me which update site is involved so that I can look at the actual details (after my walk)?

    Recall I mentioned that an optional dependency will not be installed unless there is at least one non-optional dependency or one optional greed dependency on something that is installed. Of course if you make both org.eclipse.tm and org.eclipse.terminal dependencies optional and greedy you will end up with both if both are available in one or more update sites.

  5. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    Ed Merks (@merks) : see both (final/nightly update sites) #27.

  6. merks commented on Sep 10, 2025

    @merks
    Ed Merks (merks)
    on Sep 10, 2025

    I see there is hidden stuff that I can't see. Whatever you do, it must be expressed as requirements in the p2 metadata:

    https://eclipse.dev/eclipse/markdown/?file=eclipse-equinox/p2/master/docs/Customizing_Metadata.md#capability-advice

    One can get quite fancy with negative requirements (min=0 and max=0) that you might try to use to make two things mutually exclusive. It's hard to help with hidden things...

  7. laeubi commented on Sep 10, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 10, 2025

    Last time I played around with it there was no satiable (p2) solution, because this is not really supported by P2 really without enhancing some things what would be a chicken-egg problem (if you could use "Modern P2 you would need new Eclipse with then you then could have used new terminal anyways). Also assume now you have a fresh install without any terminal, how should P2 decide if the product likes the new or the old implementation?

    So two things:

    1. The error complains about a missing (hard) requirement, so likely the discussion about p2 not install something seems to be a different problem
    2. Yes I recommended to the copilote team to install required things programmatically, what could theoretically be implemented as an own touch point, some code in the activator and similar but I'm not aware it was implemented.

    Given the goal was to support Eclipse installations that require the old terminal together with one require the new one the complaint that copilote itself not has a hard requirement seems a bit off to me. I would assume that someone else already has installed either old or new (like all EPP does) and that custom products should have a choice I don't see how this can ever be automated and actually fully fulfills the goal that copilote does not mandate any of them.

    So long story short: Product maintainer have to choose and then copilote will simply adapt to whats there.

  8. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    I would assume that someone else already has installed either old or new (like all EPP does)

    Product maintainers will not run into this problem because they fully control the platform content, this ticket is about the use case where "usual" users don't have any terminal installed, whether it is old Eclipse/EPP installation without terminal or a new one.

    Any ideas for this case?
    Any comments about providing two different features I've proposed above?

  9. merks commented on Sep 10, 2025

    @merks
    Ed Merks (merks)
    on Sep 10, 2025

    Nothing would prevent both features from being installed. Something/someone would need to choose the feature without really knowing which choice is the right/best one. But yes, two features to choose one or the other would seem okay.

  10. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    Nothing would prevent both features from being installed.

    Isn't there some possibility for bundles to be marked as conflicting? E.g. if com.microsoft.copilot.eclipse.ui.terminal is installed it should prevent any feature containing com.microsoft.copilot.eclipse.ui.terminal.tm to be installed?

    Something/someone would need to choose the feature without really knowing which choice is the right/best one.

    Sure. But it is better to select something and get valid installation (because all dependencies would be checked during install time) as not select anything and get broken one (without terminal).

  11. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    Something like p2.inf saying that one feature can only be installed if other feature is not there?
    Not same as this example, but something similar: https://github.com/spotbugs/spotbugs/blob/master/eclipsePlugin/feature_p2.inf

  12. laeubi commented on Sep 10, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 10, 2025

    this ticket is about the use case where "usual" users don't have any terminal installed, whether it is old Eclipse/EPP installation without terminal or a new one.

    So where "usual users" get their IDE from if not from the Eclipse Updatesite that since a long time ships with terminal already? Maybe they use a setup file, but then these have to choose what to include (new /old / nothing).

    Something like p2.inf saying that one feature can only be installed if other feature is not there?

    You can do many things, but again the intend was to not force a particular version, so if copilote now would force an update it won't work to upgrade/install it for an older install, what was the whole purpose of this change.

    So if both variant are equally valid how should P2 decide if nothing is installed? SO one would need something that tells you:

    1. If X is installed use A
    2. If Y is installed use B
    3. If neither X nor Y is installed use A if some other thing is larger than version V otherwise install B

    and that's something that is not possible with p2.inf and usually is deferred to the user to choose (e.g. m2e allows the user to choose to install old Maven 3.8.x or newer Maven 3.9.x but that not something the p2 algorithm can decide)

    Any comments about providing two different features #26 (comment)?

    Copilote can do it but last time it was decided to not being preferred of course it would work but still require a users choice.

  13. merks commented on Sep 10, 2025

    @merks
    Ed Merks (merks)
    on Sep 10, 2025

    Something like p2.inf saying that one feature can only be installed if other feature is not there? Not same as this example, but something similar: https://github.com/spotbugs/spotbugs/blob/master/eclipsePlugin/feature_p2.inf

    That's update advice and is generally used to help update an old name to a renamed thing.

    Something like p2.inf saying that one feature can only be installed if other feature is not there?

    I mentioned negative requirements for a reason, i.e., to answer this question; each feature could negatively require the other. (But in this case, there might well be some reason why both are needed in an installation, i.e., when installing something not yet migrated.)

  14. laeubi commented on Sep 10, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 10, 2025

    (But in this case, there might well be some reason why both are needed in an installation, i.e., when installing something not yet migrated.)

    That's the point! The whole issue arises because we do not want to enforce the newer terminal (with maybe newer platform dependencies), as otherwise copilote-eclipse plugin could simply require the new stuff in the first place.

    Second, it was claimed that maintaining two versions and have user decide what to use is not feasible (as one don't want "older users" give a bad feeling)... so many things are possible but not everything at once, there are always a compromise.

  15. iloveeclipse commented on Sep 10, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 10, 2025

    OK, so to summarize the discussion here, under given current constrants:

    1. There is no solution that would allow a single copilot feature to install without errors into a (possibly older) Eclipse installation that doesn't contain yet any terminal bundle. In order to do that, a hard requirement to a specific terminal bundle is needed, and that is exactly what copilot tries to avoid because of users still having "old" Eclipse installations which might be incompatible with "new" terminal and vice versa.
    2. Two distinct copilot features on same update site as proposed here would work, assuming the two copilot terminal bundles would be "unhidden" and included into these features. The drawback for users would be that they would need to select which one they want.
    3. Variant of 2): not one but two different update sites could co-exist, main one for "modern" terminal, second one for "legacy" terminal users only. This way most users could try to install "modern" copilot feature with hard requirement to the "modern" terminal, and existing users on older platforms could install "legacy" copilot feature that has hard requirement to the "legacy" terminal. Benefit: both features could be built from same source and the extra code that extracts and installs "hidden" terminal bundles could be removed completely. This will also solve Terminal bundles are not provided on the update site #27.
    4. Anything else?

  16. laeubi commented on Sep 10, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 10, 2025

    There is no solution that would allow a single copilot feature to install without errors into a (possibly older) Eclipse installation that doesn't contain yet any terminal bundle. In order to do that, a hard requirement to a specific terminal bundle is needed, and that is exactly what copilot tries to avoid because of users still having "old" Eclipse installations which might be incompatible with "new" terminal and vice versa.

    As far as I understand currently it can install but then misses some features. The main problem is more for the "modern" variant as it will pull in new SWT versions (e.g. due to SVG support needed) that would be incompatible with an older Eclipse Install.

    Two distinct copilot features on same update site #26 (comment) would work, assuming the two copilot terminal bundles would be "unhidden" and included into these features. The drawback for users would be that they would need to select which one they want.

    Correct

    Variant of 2): not one but two different update sites could co-exist, main one for "modern" terminal, second one for "legacy" terminal users only. This way most users could try to install "modern" copilot feature with hard requirement to the "modern" terminal, and existing users on older platforms could install "legacy" copilot feature that has hard requirement to the "legacy" terminal

    Yes, this is slightly the same as before but a user has to select the desired site. This is similar to e.g. groovy-eclipse works, that has special requirements on JDT so for each Eclipse release there is one matching groovy-eclipse updatesite.

    Anything else?

    What I proposed lately was

    1. Copilote would be installed without any of its fragments / terminal bundles
    2. On first startup it decides / ask the user / ... what of both should be there and install them additionally then programmatically, this might check what is installed, what Eclipse Version is used or what else might be relevant, this is similar on how e.g. SVN Team Providers work (you can use either "native" or "java") or m2e connectors (that depend on what you use in your projects pom.xml) and requires one more restart then maybe.

  17. xinyi-gong commented on Sep 11, 2025

    @xinyi-gong
    xinyi-gong
    on Sep 11, 2025
    Member

    Based on our previous discussion, I’ve come up with a potential solution:

    1. Instead of packaging the two Copilot terminal bundles as JAR resources for direct programmatic install, publish both as installable units on a separate update site.

    2. After the Copilot plugin is installed and the IDE restarts, programmatically check the Eclipse version at startup and, via P2, install the corresponding copilot terminal bundle from our additional update site. The overall flow is similar to (https://github.com/archimatetool/archi/blob/8e13a82a2cff744b09e5eb984f37fc4106cc8daa/com.archimatetool.editor/src/com/archimatetool/editor/p2/P2Handler.java#L184) This lets P2 resolve the required terminal dependencies properly.

    3. Restart the IDE so the installation takes effect (we can show a dialog informing them that a terminal bundle was downloaded and a restart is required).

    Since the installation goes through P2, as long as an update site with the appropriate terminal version is available in Eclipse, P2 should resolve the dependencies and we shouldn’t see “missing requirement” errors during install. Could you take a look and let me know if this sounds right? Thanks!

  18. laeubi commented on Sep 11, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 11, 2025

    xinyi-gong yes this should work and is like proposed earlier. If you have a PR just let us know or if there are any further questions.

  19. iloveeclipse commented on Sep 11, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 11, 2025

    Based on our previous discussion, I’ve come up with a potential solution:

    1. Instead of packaging the two Copilot terminal bundles as JAR resources for direct programmatic install, publish both as installable units on a separate update site.

    You don't need separate update site for that. You can have all features and units on one site.

    1. After the Copilot plugin is installed and the IDE restarts, programmatically check the Eclipse version at startup and, via P2, install the corresponding copilot terminal bundle from our additional update site. The overall flow is similar to (https://github.com/archimatetool/archi/blob/8e13a82a2cff744b09e5eb984f37fc4106cc8daa/com.archimatetool.editor/src/com/archimatetool/editor/p2/P2Handler.java#L184) This lets P2 resolve the required terminal dependencies properly.

    Here is the original problem again. How do you know which from two plugins you are going to install? In the use case here the user has no terminal bundles installed, so both plugins may or may not fit.

    But this brings me to another proposal.

    What if you would provide on same update site two Copilot features with same id but different major versions and each one with explicit dependency to either the "modern" or "legacy terminal". The important difference would be that "modern" feature would require Eclipse SDK 4.37 (and also "modern" terminal bundles) and "legacy" feature would require Eclipse SDK with the upper range set to 4.36 (and also "legacy" terminal bundles). This way no extra installation steps/checks would be needed.

  20. laeubi commented on Sep 11, 2025

    @laeubi
    Christoph Läubrich (laeubi)
    on Sep 11, 2025

    Here is the original problem again. How do you know which from two plugins you are going to install? In the use case here the user has no terminal bundles installed, so both plugins may or may not fit.

    I don't think this is a problem at that stage, because you have everything at hand to decide:

    • If nothing is installed one can decide to use the "modern" on new platforms and the "legacy" on old platforms
    • If anything is already installed use that and install the compatible one
    • If both are installed lean towards using the "modern" variant

    What if you would provide on same update site two Copilot features with same id but different major versions and each one with explicit dependency to either the "modern" or "legacy terminal".

    This is a nice idea, but P2 will always lean toward the latest version so it will try to install that if user choose it and detect it is impossible (or requires an update of a lot of stuff) if you then try to apply the update. The users need to go back, show all versions and choose an old one. I do this for cucumber-eclipse where it simply shows all versions, but it is not automatic.

  21. iloveeclipse commented on Sep 11, 2025

    @iloveeclipse
    Andrey Loskutov (iloveeclipse)
    on Sep 11, 2025

    The users need to go back, show all versions and choose an old one. I do this for cucumber-eclipse where it simply shows all versions, but it is not automatic.

    The assumption is the majority could try to (automatically) install latest, minority will fail during installation but will have a solution at hand, on same update site. Benefit is that installation is not split to multiple stages (and multiple Eclipse restarts), and most users by default will get "one click" solution.

  22. jdneo commented on Dec 9, 2025

    @jdneo
    Sheng Chen (jdneo)
    on Dec 9, 2025
    Member

    In latest nightly build, we added a check logic to check if the terminal dependency is available before install the bundle to OSGi.

    Image

    Hopefully can mitigate this issue. Please let us know if there is any issue regarding the new experience.

    There is a document to guide how to install the terminal feature bundle, any contributions are welcome if the content needs to be corrected.

  23. Sheng Chen (jdneo)
    closed this as completedon Dec 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions