Add ZipEntryStorage.getArchivePath() and deprecate its getArchive()

[HannesWell]

This should help to prevent issues like eclipse-platform/eclipse.platform.ui#2251.

What's your opinion regarding just deprecating ZipEntryStorage.getArchive() or deprecating it for removal?
We could keep it as deprecated as back-up for cases were another solution doesn't exist. But we could also use the deprecation time to work on alternatives if necessary.

The only caller in the SDK is in JDT and would be satisfied with the new method that could be applied with
eclipse-jdt/eclipse.jdt.debug#486

[github-actions]

Test Results

 1 734 files  ±0   1 734 suites  ±0   1h 28m 55s ⏱️ - 4m 22s
 3 979 tests ±0   3 957 ✅ +1   22 💤 ±0  0 ❌  - 1 
12 534 runs  ±0  12 370 ✅ +3  164 💤 ±0  0 ❌  - 3 

Results for commit bc2b51a. ± Comparison against base commit b12f857.

♻️ This comment has been updated with latest results.

[vogella]

+1 for deprecate for removal

[HeikoKlare]

If there is a (good) chance that the usage can be replaced in all existing clients, I don't see a good reason for not deprecating it for removal. It does not mean that is has to be removed, but only gives the chance to do so (in two years or so). And if a use case shows up that cannot be realized in any other way, the decision to keep the method as deprecated (and remove the "removal" flag) can also be made later, can't it?

[HannesWell]

It does not mean that is has to be removed, but only gives the chance to do so (in two years or so). And if a use case shows up that cannot be realized in any other way, the decision to keep the method as deprecated (and remove the "removal" flag) can also be made later, can't it?

Exactly. Just because an element is deprecated for removal doesn't mean it has to be removed eventually. The removal can always delayed (because a longer transition period is need or because it is forgotten etc.), the deprecation can be degraded to 'not-for-removal' to just discourage its use or can be revoked entirely. Since it cannot break clients if a method is kept this is not critical, just the removal is critical because it has the potential to break clients (and that's why the deprecation process exists).

If there is a (good) chance that the usage can be replaced in all existing clients, I don't see a good reason for not deprecating it for removal.

My problem is that I cannot tell anything about callers outside the SDK and I'm not so deeply familiar with this part of the code that I can say for sure that there is no chance that a caller for example looks up another entry in the archive.

But yes I'm also in favor in going the complete path to its end in the first step and deprecate the method for removal and if somebody has use-cases that cannot be implemented in other ways we can still adapt accordingly.

[HannesWell]

If there is no objection I plan to submit this tomorrow (Tuesday) evening.