The maintenance of having a streamlined standalone debugger that
starts as fast as possible is no longer possible. See for
example #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 #761
- Complete the removal of `build-standalone-debugger-rcp` profile
that was started in #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 #761 is reasonable.
- bring debug.product's licenses up to date
- modernize command line args to eclipse when using debug.product
Fixes#781
With the extra memory in the parent commit the build is succeeding again
and therefore we don't need tests disabled anymore.
This reverts commit bee7e0db0c.
I think with some of the recent changes (Tycho 4, API baselines,
maybe even new dependency on Platform M3) it may be that our memory
requirements have gone up substantially for the build.
Also, with Sonar in the works that also requires more memory.
Therefore see if the EF's JIPP infra will allocate 10G of ram to
our build.
This should fix all the "Killed" messages randomly in the CDT builds.
https://wiki.eclipse.org/Jenkins#What_is_killing_my_build.3F_I.27m_using_custom_containers.21
I recently split code cleanliness into two parts, and since in Jenkins
the baseline-compare-and-replace and api-baseline-check run on the main
build we don't need to run them on the cleanliness pass too. Therefore
run the "only" script in the code formatting checks stage to speed up
build and avoid duplicated work.
The Jenkins CI at EF is running very slowly recently and all
tests are timing out. The tests work fine locally and find
on GitHub actions runners.
Therefore on the Jenkins CI build without running the tests.
Includes:
- Sign all artifacts, particularly 3rd party with CDT's PGP key
- Using maven version managed and updated by EF Webmasters
- Update to latest SnakeYAML
- Move some 3rd party dependencies to Import-Package (instead of
Require-Bundle)
In 56ee2c3bb1 I got github actions
working by using default GDB on GHA, but on Jenkins we should
continue to use CDT's pre-built version of GDB.
Part of #117
* Correct the requirements according to the latest target platform
* Move to requiring Java 17
* Enable the profile in the Jenkinsfile to verify it builds
