Set the real output location for embedded jars in ApiAnalysis

[laeubi]

Currently when one configures embedded extra jars these are not found by the ApiAnalysis because they are placed in different location than the main classes.

This computes all jars and compares there resulting path with the current output location updating those if needed.

See

• PDE Jenkins build broken, API tools report errors eclipse-pde/eclipse.pde#888

[github-actions]

Test Results

   570 files  ±0     570 suites  ±0   4h 27m 39s ⏱️ + 13m 0s
   371 tests +1     364 ✔️ ±0    6 💤 ±0  0 ❌ ±0  1 🔥 +1 
1 113 runs  +3  1 093 ✔️ +2  19 💤 ±0  0 ❌ ±0  1 🔥 +1 

For more details on these errors, see this check.

Results for commit fa46d2d. ± Comparison against base commit 5cddc68.

This pull request removes 1 and adds 2 tests. Note that renamed tests count towards both.

org.eclipse.tycho.test.apitools.ApiToolsTest ‑ testVerify

org.eclipse.tycho.test.apitools.ApiToolsTest ‑ testApiBreak
org.eclipse.tycho.test.apitools.ApiToolsTest ‑ testEmbeddedJars

♻️ This comment has been updated with latest results.

[laeubi]

I was not yet able to reproduce the problem with an integration test, but with the change the PDE PR builds fine...

[laeubi]

I now used a stripped down version of the pdebuild bundle as a testcase what failed before my change but succeeds with my change.

[jukzi]

@laeubi @iloveeclipse Is it possible that this commit introduced missing output.. = bin/ in build.properties to not use org.eclipse.jdt.internal.core.JavaProject.defaultOutputLocation() leading to almost every build to fail now with API errors?

[laeubi]

leading to almost every build to fail now with API errors

Only those fail with missing information in build.properties... what is the primary input and source of truth for Tycho.

[jukzi]

We have thousends of build.properties in our workspace... . It's well defined that org.eclipse.jdt.core.IJavaProject.getOutputLocation() uses a default. Can you please roll back the change that caused this regression or fix it?

[laeubi]

We have thousends of build.properties in our workspace... . It's well defined that org.eclipse.jdt.core.IJavaProject.getOutputLocation() uses a default.

IJavaProject.getOutputLocation() does not use a default it is defined in .classpath but has nothing in relation to build.properties

Can you please roll back the change that caused this regression

No, beside that without a failing test there is no regression.

or fix it?

Maybe but not before the next release so one should simply apply the easy to apply provided mitigation.

[jukzi]

Its not feasible to update thousands of files. You are effectively blocking all development with that. That's totally inappropriate.

[laeubi]

Its not feasible to update thousands of files. You are effectively blocking all development with that. That's totally inappropriate.

We are in freeze time until end of release, it is totally inappropriate to modify "thousands" of bundles...
Only bugfixes should happen on a small amount of code, freeze is not meant to perform mass changes.

Also it is searching for "output.. = bin/" shows 399 matches in the SDK where the full build 520 modules (not all are bundles though) so at a maximum there are 121 what is not "thousands" not even one thousand.

Beside that everyone is free to provide a Testcase + PR to fix that and trigger the necessary steps for a new release afterwards if one thinks it is really critical or use any of the older releases of Tycho.