Unify nature checks and reuse existing constants from core.natures.PDE

[HannesWell]

No description provided.

[github-actions]

Test Results

  194 files   -    97    194 suites   - 97   21m 28s ⏱️ - 34m 23s
  900 tests  - 2 626    862 ✅  - 2 606  34 💤  -  24  4 ❌ +4 
1 892 runs   - 8 983  1 814 ✅  - 8 884  70 💤  - 107  8 ❌ +8 

For more details on these failures, see this check.

Results for commit 5be7b7d. ± Comparison against base commit a42910f.

This pull request removes 2626 tests.

org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test1
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test2
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test3
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test4
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test5
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test6
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingAnalysisAntTaskTests ‑ test7
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests ‑ test1
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests ‑ test2
org.eclipse.pde.api.tools.anttasks.tests.ApiToolingApiFreezeAntTaskTests ‑ test3
…

♻️ This comment has been updated with latest results.

[HannesWell]

I have now taken this as an opportunity to replace all occurrences of PDE nature and builder literals by the corresponding constants in the PDE class and to leveraging the different PDE.hasXNature methods.

Additionally I moved the isBndProject(IProject) method from BndProject to the PDE class to align it with the other methods.

I also contemplate to rename the hasXNature() method to isXProject(), which I would consider a more speaking name.
But if these names are changed, we could alternativly consider to do the opposite and move the hasXNature respectivly isXProject methods as well as the constants to the corresponding XProject classes in the same package, just like it used to be for the BndProject class.

What's the opinion of the others? Keep one central class for all nature and builder ids and hasNature() or isProject() methods? Or should those constants and methods be added to the corresponding project class?
At the moment we have a split between BNDProject and Plugin/Feature/SiteProject and I would like to unify this.

[laeubi]

I would appreciate if we could delay such cleanups/unification until the pending PRs are merged so they don't get delayed/distorted by rebase conflicts, for me central classes tend to be convoluted by more and more unrelated stuff over time so I think keeping it on the project classes seems good.

[laeubi]

I think we should have also a isJavaPluginNature(...) that checks for java+plugin nature).

[merks]

I assume you mean hasJavaPluginNature...

[laeubi]

@HannesWell still relevant?

[HannesWell]

I also contemplate to rename the hasXNature() method to isXProject(), which I would consider a more speaking name.
But if these names are changed, we could alternativly consider to do the opposite and move the hasXNature respectivly isXProject methods as well as the constants to the corresponding XProject classes in the same package, just like it used to be for the BndProject class.

Implemented that now which makes the PDE class obsolete since all methods and constants have been moved to the corresponding <Type>Project classes. Furthermore I renamed BaseProject to PDEProject since fundamental constants and methods reside there now and I think the latter name more expressive.

Now I just have to find out, why the tests are failing...