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
The long sleep at the end of each thread is to make sure that
while the test code is waiting for an event the "other" thread
doesn't finish. 3 seconds is not long enough for this.
This is similar to why we need dsf.gdb.tests.timeout.multiplier
for other tests. Especially on the build machines the tests
can run much slower causing the sleep to be insufficient.
Increasing this to 30 seconds doesn't make the test suites
take any longer, when they are all passing.
Fixes#119
Various tests are not cleaning up properly after
themselves, causing test failures on subsequent
tests. Therefore start each test by deleting
all projects.
In addition, some tests were creating their test
projects in their constructor. As all the constructors
run before all the tests as part of test discovery
it means that projects were being created in
constructor and interfering with other tests
later. With the deleting of all projects in @AfterEach
these tests would have started failing. Therefore,
change these tests to create their projects
and do other initialize tasks in the setUp method.
For older JUnit3 style tests:
This substantially slows down tests as many tests
rely on sharing the project between multiple tests and
recreating those projects on each run is slow.
Therefore this is not applied universally to
all JUnit3 tests.
For tests that are affected, those tests are moved
to JUnit5 base test.
Part of #117
On GitHub actions the org.eclipse.cdt.ui.tests.text.contentassist2
tests are running after ProposalFilterPreferencesTest and
ProposalFilterPreferencesTest was changing the default
filter and not restoring it.
Part of #117
This old test had a race condition. The failing test was trying
to verify that CDTPROJECT_ADDED was received, but if there
was a delay in the startup then another event would come in
later. So for this test use the first received event,
for the remaining tests use the last received event.
Part of #117
It may be that this test fails regularly because
another test is not cleaned up properly.
Make sure there are no unexpected projects in
the workspace.
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
