Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

eclipse 11.3 eclipse-cpp-2023-09-R-linux-gtk-x86_64 has issues with cdtdebug #591

Closed
anon99 opened this issue Oct 11, 2023 · 9 comments · Fixed by #618 or #626
Closed

eclipse 11.3 eclipse-cpp-2023-09-R-linux-gtk-x86_64 has issues with cdtdebug #591

anon99 opened this issue Oct 11, 2023 · 9 comments · Fixed by #618 or #626
Milestone
11.6.0

Comments

@anon99
Copy link

anon99 commented Oct 11, 2023

Describe the bug
Install 2023-09-R [2023-06-R works fine]
Install/setup cdtdebug
https://github.com/eclipse-cdt/cdt/blob/main/StandaloneDebugger.md
Start cdtdebug
~/cdtdebugger/cdtdebug.sh
Get a whole load of errors in logfile:-

!ENTRY org.eclipse.cdt.debug.application 4 0 2023-10-10 14:30:15.839
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [35]
Unresolved requirement: Import-Package: org.eclipse.debug.ui.actions
-> Export-Package: org.eclipse.debug.ui.actions; bundle-symbolic-name="org.eclipse.debug.ui"; bundle-version="3.18.100.v20230802-1257"; version="0.0.0"
org.eclipse.debug.ui [75]
Unresolved requirement: Require-Bundle: org.eclipse.ui.ide; bundle-version="[3.5.0,4.0.0)"
-> Bundle-SymbolicName: org.eclipse.ui.ide; bundle-version="3.21.100.v20230825-1346"; singleton:="true"

Expected behavior
Pop up a dialog requesting cdtdebug information

I concluded the installation must have internal versioning discrepancies so I deleted the whole tree and installed
eclipse-cpp-2023-06-R-linux-gtk-x86_64.tar.gz
Which works as expected.
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 14, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3
4160416 
Includes updating to latest target platform. This should
also fix eclipse-cdt#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes eclipse-cdt#591
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 14, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3
4cfa56a 
Includes updating to latest target platform. This should
also fix eclipse-cdt#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes eclipse-cdt#591
Part of eclipse-cdt#548
@jonahgraham jonahgraham mentioned this issue Nov 14, 2023
Merged
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 15, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3
2018d9e 
Includes updating to latest target platform. This should
also fix eclipse-cdt#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes eclipse-cdt#591
Part of eclipse-cdt#548
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 15, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3
69aca18 
Includes updating to latest target platform. This should
also fix eclipse-cdt#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes eclipse-cdt#591
Part of eclipse-cdt#548
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 15, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3
a985381 
Includes updating to latest target platform. This should
also fix eclipse-cdt#591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes eclipse-cdt#591
Part of eclipse-cdt#548
jonahgraham added a commit that referenced this issue Nov 15, 2023
@jonahgraham
Prepare repo for CDT 11.4.0 M3 (#618)
ddc8470 
Includes updating to latest target platform. This should
also fix #591 but it is hard to tell until after it is
integrated into SimRel and the output checked in EPP.

Fixes #591
Part of #548
@anon99
Copy link
Author

anon99 commented Nov 15, 2023

Did you build a tar-kit and check that? if not point me at it and I'll give it a try.

@jonahgraham
Copy link
Member

Did you build a tar-kit and check that? if not point me at it and I'll give it a try.

That is wonderful!

The build is running now on https://ci.eclipse.org/simrel/ and that triggers the build on https://ci.eclipse.org/packaging/ which will eventually publish its results https://download.eclipse.org/technology/epp/staging/. That whole process is expected to take probably another 6 hours.

Tomorrow we build the M3 build of the 2023-12 release (with RC1 and RC2 following in the next couple of weeks). That will be available https://www.eclipse.org/downloads/packages/release/2023-12/m3 on Friday morning at 10am (Ottawa time).

If you can test M3 that would be great.

However I am not very optimistic - all the great work that has been happening to resolve all the old third-party libraries in Eclipse ecosystem has led to some instability for the standalone debugger which is built in an "unusual" way. While I think my fix has a chance of resolving this, I am unsure. I will reopen until we get this checked through the whole flow.

@jonahgraham jonahgraham reopened this Nov 16, 2023
@jonahgraham
Copy link
Member

2023-12 M3 still does not work. Unfortunately there are a bunch of problems in M3 related to versions of libraries causing issues and we'll try to get this fixed for RC1 now.

@jonahgraham
Copy link
Member

Full log of failure: 1700188701843.log

jonahgraham added a commit to jonahgraham/packages that referenced this issue Nov 20, 2023
@jonahgraham
Test build for eclipse-cdt/cdt#591
c7baefe
jonahgraham added a commit to jonahgraham/packages that referenced this issue Nov 20, 2023
@jonahgraham
Test build for eclipse-cdt/cdt#591
9079467
jonahgraham added a commit to jonahgraham/cdt that referenced this issue Nov 21, 2023
@jonahgraham
Use the bundle providing javax.activation package in simrel
c861151 
Because javax.activation 1.2.2.v20221203-1659 is in SimRel (for now)
it gets picked by p2 over jakarta.activation-api 1.2.2 which provides
the same packages.

As and when we update to Jave EE 9 (IIUC) we should be able to solve this
in a cleaner way and not rely on the old orbit bundles. Also, if and
when all projects contributing to simrel remove 1.2.2.v20221203-1659 then
we can change too.

The other option is to try to force the jakarta.activation-api 1.2.2 into
simrel and the EPP packages, but if we accidentally end up with both in
a product then other things don't work, e.g. like this error:

<details>
<summary>frame work error details</summary>

```java
!ENTRY org.eclipse.cdt.debug.application 4 0 2023-11-20 15:06:47.456
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [101]
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
       org.eclipse.cdt.dsf [116]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
       org.eclipse.cdt.dsf.ui [119]
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.0.0"
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
       org.eclipse.cdt.gdb [121]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.8.300.202309151124"; singleton:="true"
       org.eclipse.cdt.dsf.gdb.ui [118]
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="[7.0.0,8.0.0)"
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
              org.eclipse.cdt.dsf.gdb [117]
                Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
                  -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
                Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
                  -> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
                     org.eclipse.cdt.native.serial [141]
                       No resolution report for the bundle.                Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
                  -> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
           -> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
         Unresolved requirement: Require-Bundle: org.eclipse.tm.terminal.control; bundle-version="4.0.0"
           -> Bundle-SymbolicName: org.eclipse.tm.terminal.control; bundle-version="5.5.100.202311142253"; singleton:="true"
              org.eclipse.tm.terminal.control [506]
                No resolution report for the bundle.         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
  Unresolved requirement: Require-Bundle: jakarta.activation-api; bundle-version="[1.2.2,2.0.0)"
    -> Bundle-SymbolicName: jakarta.activation-api; bundle-version="1.2.2"
       jakarta.activation-api [30]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="4.2.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb.ui; bundle-version="7.0.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.gdb.ui; bundle-version="7.2.0.202211062329"; singleton:="true"
       org.eclipse.cdt.gdb.ui [122]
         No resolution report for the bundle.  Bundle was not resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"] because it is exposed to package 'javax.activation' from resources jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"] and javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"] via two dependency chains.

Chain 1:
  org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
    require: (&(osgi.wiring.bundle=jakarta.activation-api)(&(bundle-version>=1.2.2)(!(bundle-version>=2.0.0))))
     |
    provide: osgi.wiring.bundle: jakarta.activation-api
  jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"]

Chain 2:
  org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
    require: (&(osgi.wiring.bundle=jakarta.xml.bind-api)(&(bundle-version>=2.3.3)(!(bundle-version>=3.0.0))))
     |
    provide: osgi.wiring.bundle; bundle-version:Version="2.3.3"; osgi.wiring.bundle="jakarta.xml.bind-api"
  jakarta.xml.bind-api [osgi.identity; osgi.identity="jakarta.xml.bind-api"; type="osgi.bundle"; version:Version="2.3.3"]
    import: (osgi.wiring.package=javax.activation)
     |
    export: osgi.wiring.package: javax.activation
  javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"]
	at org.eclipse.osgi.container.Module.start(Module.java:463)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
```

</details>

The underlying problem here is that the debug application's "product" that
gets converted to a config.ini at CDT build time doesn't expose its
dependencies fully to p2, so we end up with a built product in EPP that
doesn't have everything listed in config.ini.

There is significant maintenance overhead and it is growing to keeping
standalone as it is now working. Other options should probably be considered,
such as using the config of the full product when launching.

Fixes eclipse-cdt#591
@jonahgraham jonahgraham mentioned this issue Nov 21, 2023
Merged
jonahgraham added a commit that referenced this issue Nov 21, 2023
@jonahgraham
Use the bundle providing javax.activation package in simrel (#626)
4aa793a 
Because javax.activation 1.2.2.v20221203-1659 is in SimRel (for now)
it gets picked by p2 over jakarta.activation-api 1.2.2 which provides
the same packages.

As and when we update to Jave EE 9 (IIUC) we should be able to solve this
in a cleaner way and not rely on the old orbit bundles. Also, if and
when all projects contributing to simrel remove 1.2.2.v20221203-1659 then
we can change too.

The other option is to try to force the jakarta.activation-api 1.2.2 into
simrel and the EPP packages, but if we accidentally end up with both in
a product then other things don't work, e.g. like this error:

<details>
<summary>frame work error details</summary>

```java
!ENTRY org.eclipse.cdt.debug.application 4 0 2023-11-20 15:06:47.456
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: org.eclipse.cdt.debug.application [101]
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
       org.eclipse.cdt.dsf [116]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
       org.eclipse.cdt.dsf.ui [119]
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf; bundle-version="2.0.0"
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
       org.eclipse.cdt.gdb [121]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.4.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb.ui; bundle-version="2.8.300.202309151124"; singleton:="true"
       org.eclipse.cdt.dsf.gdb.ui [118]
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.ui
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf.ui; bundle-version="2.7.200.202311031553"; singleton:="true"
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="[7.0.0,8.0.0)"
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
              org.eclipse.cdt.dsf.gdb [117]
                Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
                  -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
                Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
                  -> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
                     org.eclipse.cdt.native.serial [141]
                       No resolution report for the bundle.                Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb; bundle-version="7.0.0"
                  -> Bundle-SymbolicName: org.eclipse.cdt.gdb; bundle-version="7.2.100.202303140100"; singleton:="true"
         Unresolved requirement: Require-Bundle: org.eclipse.cdt.native.serial; bundle-version="1.1.100"
           -> Bundle-SymbolicName: org.eclipse.cdt.native.serial; bundle-version="11.4.0.202311201859"
         Unresolved requirement: Require-Bundle: org.eclipse.tm.terminal.control; bundle-version="4.0.0"
           -> Bundle-SymbolicName: org.eclipse.tm.terminal.control; bundle-version="5.5.100.202311142253"; singleton:="true"
              org.eclipse.tm.terminal.control [506]
                No resolution report for the bundle.         Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf
           -> Bundle-SymbolicName: org.eclipse.cdt.dsf; bundle-version="2.12.0.202211062329"; singleton:="true"
  Unresolved requirement: Require-Bundle: jakarta.activation-api; bundle-version="[1.2.2,2.0.0)"
    -> Bundle-SymbolicName: jakarta.activation-api; bundle-version="1.2.2"
       jakarta.activation-api [30]
         No resolution report for the bundle.  Unresolved requirement: Require-Bundle: org.eclipse.cdt.dsf.gdb; bundle-version="4.2.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.dsf.gdb; bundle-version="7.1.200.202309151124"; singleton:="true"
  Unresolved requirement: Require-Bundle: org.eclipse.cdt.gdb.ui; bundle-version="7.0.0"
    -> Bundle-SymbolicName: org.eclipse.cdt.gdb.ui; bundle-version="7.2.0.202211062329"; singleton:="true"
       org.eclipse.cdt.gdb.ui [122]
         No resolution report for the bundle.  Bundle was not resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint violation. Unable to resolve resource org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"] because it is exposed to package 'javax.activation' from resources jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"] and javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"] via two dependency chains.

Chain 1:
  org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
    require: (&(osgi.wiring.bundle=jakarta.activation-api)(&(bundle-version>=1.2.2)(!(bundle-version>=2.0.0))))
     |
    provide: osgi.wiring.bundle: jakarta.activation-api
  jakarta.activation-api [osgi.identity; osgi.identity="jakarta.activation-api"; type="osgi.bundle"; version:Version="1.2.2"]

Chain 2:
  org.eclipse.cdt.debug.application [osgi.identity; osgi.identity="org.eclipse.cdt.debug.application"; type="osgi.bundle"; version:Version="11.4.0.202311201855"; singleton:="true"]
    require: (&(osgi.wiring.bundle=jakarta.xml.bind-api)(&(bundle-version>=2.3.3)(!(bundle-version>=3.0.0))))
     |
    provide: osgi.wiring.bundle; bundle-version:Version="2.3.3"; osgi.wiring.bundle="jakarta.xml.bind-api"
  jakarta.xml.bind-api [osgi.identity; osgi.identity="jakarta.xml.bind-api"; type="osgi.bundle"; version:Version="2.3.3"]
    import: (osgi.wiring.package=javax.activation)
     |
    export: osgi.wiring.package: javax.activation
  javax.activation [osgi.identity; osgi.identity="javax.activation"; type="osgi.bundle"; version:Version="1.2.2.v20221203-1659"]
	at org.eclipse.osgi.container.Module.start(Module.java:463)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel$2.run(ModuleContainer.java:1852)
	at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor$1$1.execute(EquinoxContainerAdaptor.java:136)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1845)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1786)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1750)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1672)
	at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:234)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:345)
```

</details>

The underlying problem here is that the debug application's "product" that
gets converted to a config.ini at CDT build time doesn't expose its
dependencies fully to p2, so we end up with a built product in EPP that
doesn't have everything listed in config.ini.

There is significant maintenance overhead and it is growing to keeping
standalone as it is now working. Other options should probably be considered,
such as using the config of the full product when launching.

Fixes #591
@jonahgraham
Copy link
Member

While I think (hope) that #626 fixes the issue - until I can test fully integrated I can't be sure. Reopening the auto close until that check is done.

@jonahgraham jonahgraham reopened this Nov 21, 2023
@jonahgraham
Copy link
Member

No actual progress on this - it won't be resolved for 2023-12. The latest build still fails because we can't express to EPP build what is needed to make the standalone - and the changes to the third party libraries makes it hard to resolve.

I think we need a new way to resolve this so that we can resolve the dependencies properly.

@jonahgraham
Copy link
Member

Perhaps there is some Tycho feature that can help - I have raised eclipse-tycho/tycho#3076

@jonahgraham jonahgraham added this to the 11.5.0 milestone Nov 27, 2023
@jonahgraham jonahgraham removed this from the 11.5.0 milestone Mar 6, 2024
@jonahgraham
Copy link
Member

Unfortunately had to clear this milestone. Someone needs to dedicate some time to work on this.

@jonahgraham jonahgraham mentioned this issue May 10, 2024
Closed
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
@jonahgraham
Change standalone debugger to no longer limit number of bundles
f628420 
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.

Fixes eclipse-cdt#781

- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
@jonahgraham
Change standalone debugger to no longer limit number of bundles
1765f77 
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes eclipse-cdt#781
@jonahgraham jonahgraham mentioned this issue May 12, 2024
Merged
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
@jonahgraham
Change standalone debugger to no longer limit number of bundles
89667cd 
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes eclipse-cdt#781
jonahgraham added a commit to jonahgraham/cdt that referenced this issue May 12, 2024
@jonahgraham
Change standalone debugger to no longer limit number of bundles
0568568 
The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example eclipse-cdt#591 - therefore when using standalone debugger, use
the same sets of plug-ins/features as the product it is installed
in uses. The side effect is that the standalone debugger in this
use case will start slower and extra "stuff" will be present in
this UI.

For people just building the standalone debugger, provide a minimum
feature set. This will be many more bundles than before, but
should still provide a reasonably small set that starts well.

This simplification also includes removing the the duplicates set
of CDT docs (debug/org.eclipse.cdt.debug.application.doc). These
provided a simplified version of CDT's documentation targetted
at just standalone debugger. However there are a few problems related
to this duplication:

- The two sets of docs were not kept in sync
- The standalone docs appear in the online help, leading to
  duplicated entries
- With the config.ini changes above, there is no way to exclude
  the main docs in the standalone case, so remove the duplicate

A number of directly related clean-ups are included too:

- Remove the `ConfigGenerator.java` that stopped being referenced
  in PR eclipse-cdt#761
- Complete the removal of `build-standalone-debugger-rcp` profile
  that was started in eclipse-cdt#761. There is a small drawback to not having
  this profile, the standalone debugger is very slow to build
  compared to the rest of CDT. If this becomes a problem, restoring
  this profile along with the changes made in eclipse-cdt#761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product

Fixes eclipse-cdt#781
@jonahgraham jonahgraham added this to the 11.6.0 milestone May 12, 2024
@jonahgraham
Copy link
Member

We have done a major refactor on how cdtdebug is built. I think this resolves the issue, but some minor differences in behaviour may be observed.

More details in #782

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
11.6.0
2 participants
@jonahgraham @anon99