Simplify PDE classpath resolving #2671
Merged
Conversation
This file contains 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
I've noticed that starting SpotBugs analysis in the IDE where workspace contains lot of plugin project takes sometimes longer as the analysis itself. Turned out, we do lot of duplicated work resolving plugins classpath, while Eclipse already resolved almost everything for us via JavaRuntime.computeDefaultRuntimeClassPath(). Just removing lot of code here allows reduce startup times for spotbugs analysis, especially if running analysis on ~100 plugins in parallel.
hazendaz
approved these changes
Nov 1, 2023
|
LGTM and makes sense. Thanks! |
|
@iloveeclipse Can you add an entry to the change log and send another PR so we don't lose track of this change? |
|
@hazendaz : you were a bit too fast, and I was not careful enough to declare this PR as a draft. I've did some real life testing today on my two major workspaces (one including most of Eclipse SDK and another one including our ~200 product bundles) and found some corner cases where we still need to perform some more work to avoid "blabla class not found" errors, but fortunately this work does not re-introduce reported issue here, so it would still fix the long startup time. I will push a new PR soon and along with that also updated README. |
1 task
Here is it: #2673 |
iloveeclipse
added a commit
to iloveeclipse/spotbugs
that referenced
this pull request
Nov 2, 2023
The fix spotbugs#2671 removed a bit more code as needed to fix slow PDE classpath resolving of the PDE project classpath, resulting in "The following classes needed for SpotBugs analysis on project XYZ were missing" warnings reported for few plugin projects. This is a corner case, but not nice. After a bit more evaluation, turned out, we do not need to manually (recursively) resolve plugins classpath looking in each dependent *workspace* PDE bundle (which caused repetitive classpath resolving and huge overhead), but we still need to add all libraries from all *bundle dependencies* (recursive), even if they do not contribute to the project runtime classpath (OSGI does that behind the scenes, so PDE doesn't include them by default). So this patch restores some of that PDE classpath extension logic removed via spotbugs#2671 (but still solves original issue reported in spotbugs#2671). See spotbugs#2671
hazendaz
pushed a commit
that referenced
this pull request
Nov 2, 2023
The fix #2671 removed a bit more code as needed to fix slow PDE classpath resolving of the PDE project classpath, resulting in "The following classes needed for SpotBugs analysis on project XYZ were missing" warnings reported for few plugin projects. This is a corner case, but not nice. After a bit more evaluation, turned out, we do not need to manually (recursively) resolve plugins classpath looking in each dependent *workspace* PDE bundle (which caused repetitive classpath resolving and huge overhead), but we still need to add all libraries from all *bundle dependencies* (recursive), even if they do not contribute to the project runtime classpath (OSGI does that behind the scenes, so PDE doesn't include them by default). So this patch restores some of that PDE classpath extension logic removed via #2671 (but still solves original issue reported in #2671). See #2671
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.
I've noticed that starting SpotBugs analysis in the IDE where workspace contains lot of plugin project takes sometimes longer as the analysis itself.
Turned out, we do lot of duplicated work resolving plugins classpath, while Eclipse already resolved almost everything for us via JavaRuntime.computeDefaultRuntimeClassPath().
Just removing lot of code here allows reduce startup times for spotbugs analysis, especially if running analysis on ~100 plugins in parallel.
CHANGELOG.mdif you have changed SpotBugs code