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.
Warning in build.properties will be errors when they run
in the tycho build, like this:
```
Error: Failed to execute goal org.eclipse.tycho:tycho-packaging-plugin:2.7.5:package-plugin
(default-package-plugin) on project org.eclipse.cdt.core.tests:
/home/runner/work/cdt/cdt/core/org.eclipse.cdt.core.tests/build.properties:
bin.includes value(s) [test.xml] do not match any files. -> [Help 1]
```
So make them errors in the workspace so that the issue is
detected before push.
Some build.properties issues don't affect the build, but
are still indicative of a problem.
The CDT Cleanup profile had a bunch of extra cleanups applied to it, this
prevents running the CDT cleanup profile manually to simulate running the
save actions on all Java files
Change-Id: Iad491e1258a4ba90d81d1457ea0f6779e3663e38
Using the Consumer interface means that code navigation is substantially
harder. e.g. open ImportMemoryDialog and do a call hierarchy on who
calls scrollRenderings.
You end up in Consumer.accept, which (naturally) has 100s of callers, so
identifying which ones are relevant is very difficult.
Change-Id: I8817568e992955d5b01a591a9cffb2447b9e5008
The CDT 9.x code scrolled once, to the start address of the import
when the import finished. The refactoring done early in the CDT 10.x
cycle (Bug 562164) instead scrolled repeatedly, generally once
per line of the input file, until finally scrolling one last time
to the byte right after the last imported byte.
Change-Id: I79f2a17c7a5feb19a463002ce19dec9d22afc90f
Added "number of units to retrieve" parameter to ReadMemory#from
Fixed result compare for text-based formats
Returning back 64KiB DATA_PER_TRANSFER optimization
Reworked FileExport from "O extends AutoCloseable"
Renamed ReadMemory to IReadMemory
Change-Id: Id7eb51015884d5dbffa5e91e9601f5e6ddb52d90
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Add tests for PlainTextImport/PlainTextExport
Add tests for RAWBinaryImport/RAWBinaryExport
Add tests for SRecordImport/SRecordExport
Change-Id: I4e489498dd6fb451621785743284a31a2f57516f
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
