Using:
```
mvn org.eclipse.tycho.extras:tycho-version-bump-plugin:4.0.12:update-manifest
```
and then multiple iterations to bump the bundle-version:
```
mvn verify org.eclipse.tycho:tycho-versions-plugin:4.0.12:bump-versions -Dtycho.bump-versions.increment=100 -DskipDoc=true -DskipTests=true -P baseline-compare-and-replace -fae -Djgit.dirtyWorkingTree-cdtDefault=warning
```
Make sure bounds of all dependencies match what we built against. This
prevents issues such as Bug 536448 from recurring. In 2025-06 there
are a number of Eclipse Platform changes that make CDT susceptible
to these types of issues again.
Note that this change is similar to previous iterations, such
as 1087dc5f22, but with the automatation
we can now apply this to *all* bundles.
In addition, with the tighter version constraints, building from
simrel repo for the jniheader (releng/scripts/do_rebuild_natives.sh)
is no longer sufficient. This speedup has been removed as it was probably
incorrect to have by default.
The api filters were introduced because some bundles are re-exported. Those
re-exported bundle requirements mean that technically we need to bump
the version, but in reality we effectively required the range as now
documented anyway, so doing a major version bump is unneeded.
All the about.html files are updated, so every bundle that hasn't
already had a bump in 10.7 needs one now
Change-Id: I6143d2fbe77a58a3a6d2f4a226d96087117f9ac1
While most of these commands don't actually have spaces in them, or
their arguments, avoid the deprecated methods.
Change-Id: If7b4324695699d5a6d9a2f8a979657977486d8a4
- modify ProcessFactory to prefix commands with flatpak-spawn
when running under Eclipse flatpak
- add new FlatpakLaunch class to dsf.gdb to do a prelaunch
of gdbserver and set up remote port settings when debugging
local C/C++ application under Eclipse flatpak
- add new tab to gdb when running under Eclipse flatpak
to allow user to specify gdbserver and port number
- add new org.eclipse.cdt.flatpak.launcher plug-in which
contains a FlatpakCommandLauncherFactory to handle copying
header files from host to workspace when developing under
Eclipse flatpak
- add new FlatpakCommandLauncher class which simply extends
CommandLauncher and can be used for debugging purposes to
distinguish from regular command launcher
- also add new FlatpakHeaderPreferencePage to allow C/C++ users
to delete copied headers if needed
- dynamically add the headers preference page from
FlatpakCommandLaunchFactory
if running under Eclipse flatpak
- add new ICommandLaunchFactory3 to add an interface to check if
headers have been modified/removed and scanner info refresh
is required
- add new org.eclipse.cdt.flatpak.launcher-feature
- give higher priority to ContainerCommandLauncherFactory so if
running on Eclipse flatpak, the flatpak factory won't be chosen
if both apply (i.e. building in a container but running on
Eclipse flatpak)
Change-Id: Id68e60c4dd37c4494af10440231ac7b7bbec8d17
