The org.eclipse.remote.* version bumps were all because of
BREE change since the last release.
The api filters are removed because of the baseline bump
Change-Id: Ic7317dafa9872bb737502654a726823a35ec47b3
Use info from https://projects.eclipse.org/releases/2021-12 to determine
the versions of components + M1 build of Eclipse Platform.
Orbit has not done an M1 release.
Change-Id: I1b23daeae7ae280502db5155e4a7bd34b89e7db4
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Also-by: Jonah Graham <jonah@kichwacoders.com>
In the p2 site all the o.e.remote features are appearing in the
Uncategorized category, AFAICT this is because the category.xml
file was not actually valid. Note that the PTP version
in https://download.eclipse.org/tools/ptp/builds/remote/3.0/2021-09
also showed everything as uncategorized, so this commit is actually
an improvement on presentation.
Change-Id: Ic3304c8e57131efd3c7adc6eec021f72e6ba1a36
The bundles have all had version bumped to make it easier to
differentiate the bundles built since integration into CDT.
Note the feature versions have already been aligned with CDT.
Change-Id: I68141e31559df3897414a50ee52c3ede49d429df
The proxy server products need to be built and signed before being
moved to the correct location. Prior to this patch this happened
in pre-integration-test phase, meaning that "mvn package" would
fail to build CDT successfully.
Therefore "pull" rather than "push" proxy-server to individual bundles.
If signing is not enabled, the proxy server product won't be signed,
but that is expected.
Also, to make sure the archiving happens in package phase, we need to
have some duplication so that archiving always is listed after signing.
Change-Id: I09ef2b6384ab6f6573352f85c068756e3792512f
This is applying the per-project code formatting rules that would
be applied on save in the JDT editor
See also Bug 540373
Change-Id: Ie93f9b640d0f0cfce8711e72fabc87f6a89634fa
Note that due to dependencies, the effective BREE was already
Java 11, this change simply formalizes that
Change-Id: I834766caf02a0ed5e1992b61050ca1bf9c6bb390
Includes removing redundant content that will be provided by CDT:
- .mvn/extensions.xml
- .gitignore
- CONTRIBUTING
- LICENSE
- NOTICE
- root pom.xmls
Note: if you get to this commit when searching history or
doing git blame, try adding --follow to force the history
back before this move.
Change-Id: I42bdbb2cf8e7f07d6608c32eaabf2b54151a1fb1
We must ensure that memory data is initialized before the restoration of
persisted memory monitors is triggered.
Change-Id: Id87809bb4de80785dbcfe444fd782efe41d6d086
Signed-off-by: John Dallaway <john@dallaway.org.uk>
and:
- bump versions of all the docs plug-ins.
- improve comment so that next person can do it more easily
- change to using https in the URL
Change-Id: I62bd970f03e1ce081d4655ddbf6c742be2623acd
Use eclipse.target.platform.latest
Sync with Target
Change-Id: Ife2508edb72eaa45bfe33618d3cbde47a5d34d6a
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
-framework JavaVM is no longer needed for a while and in
latest Xcode is removed as an option
x86 on macOS is no longer supported by recent Xcode, so drop it
from CDT. x86 hasn't been supported in Platform for a while, so
it wasn't actually usable.
Change-Id: I149722b168fe9819ee334d4afd25ae624b1664c5
Side effect is that the indentation in the transformer now
works properly, so the extra newlines inserted everywhere
can be removed.
This change was done by changing the output to an OutputStream
instead of a Writer so that the XML handler could set the
encoding to match what was in the settings, i.e.:
transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8");
The non-translated language IDs are used in preference to the
translated names when importing. The export now puts that ID
(when available) in the output file. The ID is available on
normal user files (C, ASM, C++) and not on object files. The
object files probably don't have languages settings that are
exported, but this code does not exclude them from being exported.
Change-Id: I46de004bb8c6a0ca05210487a5d33390d397c720
Format both baseline and regular targets
Change-Id: Idc3c4739fdca7c4311981dfc3fe652713bc024a2
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Format both baseline and regular targets
Change-Id: I2498e77df38af844e2cbdb10376a3f2917e0b763
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Updated Baseline to 2021-09
Updated Target to 2021-09+
Change-Id: I9dd301b2b759452c743238626ac671008e2cd254
Signed-off-by: Alexander Fedorov <alexander.fedorov@arsysop.ru>
Previously custom launch config tabs could cause a Class Cast Exception
in the Launchbar's edit launch config dialog if they did not use the
GridLayout. Since ed1e058 the launchbar dialog no longer tries to give
the tab control GridLayoutData, avoiding the problem and allowing custom
tabs to use whatever layout they wish.
This change updates the launchbar UI tests to Junit 5 and adds a new
SWTbot test to verify the dialog no longer throws a CCE in this case.
Signed-off-by: Mat Booth <mat.booth@gmail.com>
Change-Id: I05c85cd5f0f5996e46601990b72602383b3fac06
The current situation is that:
* launch configuration dialog tabs scroll correctly in the standard
Eclipse platform dialog, but not at all in the Launchbar-specific dialog
* some CDT-supplied launch configuration dialog tabs try to manage their
own scrolling behaviour to fix scrolling in the Launchbar-specific
dialog but this breaks scrolling for that tab in the standard Eclipse
platform dialog.
This change fixes the launchbar-specific editor dialog to use a scrolled
composite instead of a regular composite on which to layout the content
of each tab -- This gives the launchbar's configuration editing dialog
exactly the same scrolling behaviour as the standard Eclipse platform
configuration editing dialog.
And also fixes any CDT-supplied tabs that try to manage their own
scrolling behaviour so now all tabs have the same behaviour when viewed
in the Launchbar-specific dialog as they do when viewed in the standard
Eclipse platform dialog.
Change-Id: I0d7364a24ca48bb125cae9518728b4c93b93545d
Signed-off-by: Mat Booth <mat.booth@gmail.com>
Include the top-level subdir.mk only when one was actually generated
(i.e. when there are source files there), just like for all other
subdir.mk, otherwise a stale one from earlier when there were source
files that have since been removed may be picked up, causing "No rule to
make target" errors.
In some cases (from bug 303953), the removal would be noticed and the
stale subdir.mk be overwritten by a correct empty one, avoiding the
error, but not in the following cases:
- When CommonBuilder.performCleanning() decides that a full rebuild is
needed, regenerateMakefiles() is called instead of generateMakefiles(),
which doesn't get the delta.
- When the refresh in which Eclipse notices the removed source file
happens as part of a build (one that probably failed because the
makefiles weren't updated yet), the next build after that apparently
does not get the delta containing the removal anymore.
Change-Id: Id15b424f02dd5c513d2124620c0c8699d61874fd
Signed-off-by: Christian Walther <walther@indel.ch>
Several parts of makefile output were generated by iterating over
HashMaps, which do not have a deterministic iteration order. Use
TreeMaps instead to output in sorted order. This is possible now that
the API function with return type HashMap is no longer public API and
can be changed to return Map instead.
Benchmark files for affected tests are updated to the new ordering.
This would not be strictly necessary: the tests would also succeed
without, since org.eclipse.cdt.managedbuilder.testplugin.
ManagedBuildTestHelper.compareMakefiles() uses a reordering-tolerant
comparison. However, recording the new (now hopefully stable) order
makes future development on makefile generation easier by avoiding
spurious diff output when tests fail due to changes to other parts of
makefiles.
Change-Id: I20f2e51bd5b9e3bcc5da245d781ca5b4a34fc0b2
Signed-off-by: Christian Walther <walther@indel.ch>
