Instead of using assertTrue, but assertEquals we get nice
error messages that show the contents of the collections.
Using assertEquals(List.of() instead of assertArrayEquals(...
because that gives nicer error messages.
Part of #117
The test "abused" the JUnit3 ability to control test order and
required all tests to run in the given order to work.
Refactored the test to remove all redundant try/catch and
provide a more traditional flow.
Part of #117
While it may be that the tests don't directly rely
on JUnit5, the IDE requires JUnit5 in the classpath
or else the launch config doesn't work with this error:
Cannot find class 'org.junit.platform.commons.annotation.Testable'
on project build path.
Part of #117
JDT thinks this is a test and will run it in the IDE and display
an error. But it is only used to compose other tests, by making
it abstract the IDE won't see it anymore.
Part of #117
This is an ancient (2004) test that does not apply, was never
referenced in the Suites and whose name doesn't match standard
pattern.
It tried to import ancient versions of projects as well, which
would kick off the project converter UI that can't be disabled
from the core plug-in.
All in all, this test adds nothing of value.
Part of #117
This code seems to be trying to optimize across tests.
This change isolated each individual test better.
Also removed is a bunch of effectively unused test code.
Part of #117
Some of these tests left behind projects, by chaning them
to extend BaseTestCase5 the resource cleanup happens
and the tests are cleaned up properly
Part of #117
Ideally the code itself should also be deleted from CDT, but
this test is super flaky and I cannot seem to convert it to
JUnit5 so I can properly mark it as flaky. Therefore
the test is now simply gone.
Part of #117
The resource helper is widely used, but when it deletes
projects, it leaves their contents on disk. Fix this
so that the contents on disk is deleted.
Part of #117
Maybe once upon a time this lifecycle did something,
but now in setUp fProject is always null and therefore
the project was never getting deleted as the fProject
that deleteProject saw was different than
the tests.
Part of #117
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
Having the test suites means that tests run multiple times
when running in the UI. Most suites just ran the tests in
that package, so their value, especially with the transition
to JUnit5 is minimal.
Note that the suites are not used when running build
with Tycho/Maven
Part of #117
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.
* Add ManagedBuildManager#createConfigurationForProject()
This should allow ISV's to create MBS based project with a
vendor-specific build-system ID without using internal API.
Update New & Noteworthy
Signed-off-by: 15knots <11367029+15knots@users.noreply.github.com>
If a .cproject references a binary parser ID that is not in
the plug-in XML, or in the XML, but marked as private, the
UI cannot display the binary parsers and was raising an
ArrayIndexOutOfBoundsException as below.
This fix rewrites the array handling using collections.
```java
!ENTRY org.eclipse.ui 4 0 2022-11-04 09:44:27.409
!MESSAGE Unhandled event loop exception
!STACK 0
java.lang.ArrayIndexOutOfBoundsException: Index 7 out of bounds for length 7
at org.eclipse.cdt.ui.newui.BinaryParsTab.updateData(BinaryParsTab.java:253)
at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.setVisible(AbstractCPropertyTab.java:253)
at org.eclipse.cdt.ui.newui.BinaryParsTab.setVisible(BinaryParsTab.java:221)
at org.eclipse.cdt.ui.newui.AbstractCPropertyTab.handleTabEvent(AbstractCPropertyTab.java:630)
at org.eclipse.cdt.ui.newui.AbstractPage.updateSelectedTab(AbstractPage.java:412)
at org.eclipse.cdt.ui.newui.AbstractPage$4.widgetSelected(AbstractPage.java:382)
```
Changed the execute to take the cwd to run the command in and
clean up the related code, including some error message
handling and removing some redundant code.
Fixes#125
It would be nice to have an icon here, but it has been
fine not having it for 14 years, so just remove reference
to clean up error.
Fixup for e5ae2a94a7
This is mostly a no-op change, but fixes the error
about incorrect reference.
The descriptorUI extension used an ID that never existed,
and the code in ConfigSelector just fell back on
DefaultDescriptorLabelProvider it none were found, so
the user visible change here is nothing.
Fixup for 8f8c2e02b6
The adaptable type that was listed doesn't exist.
This is only used to get the correct icon/label for these
type of adapters, so the effect is minor.
Fixup for 9aee6c4850
