[concept] Let PDE compute required packages using a CompilationParticipant #1926
+187
−0
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There are some case where the JDT concept of classpath restrictions do not match well the OSGi runtime handling of imported packages these include: - inlined constants are never visible at runtime and therefore no import required and no restriction issue - indirect references through super types are handled by the classpath of the providing bundle and not the consumer - methods inherited from superclasses are also not a problem at all This is now a radical change in how PDE handles the case and detects problems: - instead of using access restrictions that try to emulate the runtime behavior, it computes a full set of transitive classpath items and add them unrestricted (except for internal packages to get warnings there) - then during compilation we dynamically compute the actual set of required imports at runtime - if any of these imports are missing in the manifest we create a problem and suggest suitable quickfix This has the benefit that we are in full control over what is detected, how it is reported and where it is reported. It also gives much more flexibility in improving user experience, for example one might even want to have some "autoimport" feature that is adding /removing packages on demand so do not bother the user with doing this daunting task manually.
laeubi
force-pushed
the
pde_compile_participant
branch
from
e117328 to
b178887
Compare
Test Results 618 files - 147 618 suites - 147 52m 57s ⏱️ - 1m 21s For more details on these failures, see this check. Results for commit b178887. ± Comparison against base commit e7b608f. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are some case where the JDT concept of classpath restrictions do not match well the OSGi runtime handling of imported packages these include:
This is now a radical change in how PDE handles the case and detects problems:
This has the benefit that we are in full control over what is detected, how it is reported and where it is reported. It also gives much more flexibility in improving user experience, for example one might even want to have some "autoimport" feature that is adding /removing packages on demand so do not bother the user with doing this daunting task manually.
This is currently a concept!
This means the PR description might not match fully the current implementation, it is likely not to be merged soon but allows discussion and exploring of possibilities of further enhancements what might then further refine the concept presented here or act as a reference to other improvements we need from the components we are using so answering the question "why" for new features and showing concrete code examples.
This would then require a similar change in Tycho, where we already do some preprocessing and handling based on class file analysis.