Initializing plugin in a mid-sized monorepo takes hours #129
Comments
tomasaschan
changed the title
|
Yikes, it's likely going to anayze the entire mono-repo. There are a few performance issues with JDTLS that we don't see in Eclipse. When opened inside a workspace, the extension tries to walk up the tree to discover the workspace root. In the workspace root it looks for a project view in Our primary use case is a mono-repo & monolith. Thus, we usually open VS Code in the Bazel workspace root and use Also, can you describe the project layout? Is it more Maven like or more Bazel like? Bazel like: verify fine grained, eg., BUILD files within Java packages to slice Java packages into smaller libs/units For Maven like projects it may make sense to tweak the Have you tried importing into Eclipse? The output/feedback is usually better there. |
|
@tomasaschan Did you use the pre-release version or the latest release version? I noticed we haven't pushed a release to the stable channel in a while. |
|
@guw I'm using the latest stable. I can try with the preview version, but I'm not tempted at restarting this and potentially throwing away all progress... The project is more maven-like (most sub-projects are imported from maven "polyrepos") but not everything is Java either. The Do you have suggestions on what I should put there? |
|
I released 1.4.0 this morning. That's the version you should use. The older one was definitely broken. Add this: The glob pattern for sources is need because folders are matched as a whole from workspace root. In general, everything in the project view file is relative from workspace root. |
|
I still see the same behaviors with the 1.4.0 plugin version and those additions to my |
|
What Bazel version are you using? 7.4.1? Did you limit the directories in the Is your project building without issues in the command line? The extension is attempting a build, too. Using the Bazel disk cache might speed things up a bit. |
|
Ah, I see. Yes, 7.4.1: And yes, a command-line It seems the plugin still tries to initialize and do things for every project in the monorepo - it takes many hours and despite having it on in the background at work all day I haven't managed to have it finish once. Every time I close and re-open the project it starts over from scratch and seems to not have anything cached from before... :/ |
|
In that case I recommend deleting the VS Code data/workspace created by JDTLS and start over. https://github.com/redhat-developer/vscode-java/wiki/Troubleshooting |
|
That seems to have just set it back to start over again. Not sure how much detail I can share about the repo structure and contents (there's a lot of proprietary info in there...) but I did notice the activation script started with |
That's ~40% of what I have here. :) Do you see any progress in the Bazel Console in VS Code? Is there any output? Can you try loading it with Eclipse? |
|
Hi again! Sorry for the silence here - I had to put this aside for a bit and focus on other stuff... I have since done two things:
and now I notice that the plugin seems to load pretty quickly - within a minute or so from opening the window, status says "Java: Ready"! However, despite Do I need to set up something more for the plugin to pick up dependencies and make them available in the classpath, compared to what bazel itself needs in order to find them?
|
|
Can you inspect the Java Project view? It should show which Java projects were detected and their classpath. Also, the error log from the Java language server would help for troubleshooting. |
|
I have stuff like this in the Java language server logs: ...and I don't have a Java project view at all...! What other extensions are expected to be installed alongside this one? |
|
Another example error: |
|
Which version of the extension do you have installed? |
|
With the version I had this morning, a new log from just opening the project todayAll of it seems to stem from |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We have a monorepo with a couple of hundred subcomponents (as determined by
find . -name BUILD.bazelin the monorepo root). Opening a subpath of that monorepo and initializing the plugin has been running for hours and I have no idea how long it's going to take until it completes.A few steps I've noticed took a lot of time:
.eclipseprojects for each java componentComputing Bazel project classpathsfor a bunch of stuff; unclear to me what the scope of each of those is, because sometimes it seems like it's doing it for an entire package, and other times for just a single file.At the step I'm currently at, every so often (a few times per minute?) the
Java Build Statusview outputs something like{hash} {repo-name}> bazel query //{path-to/subcomponent}:all [Done].Is it expected that this extension doesn't work well with monorepos? Is it expected that it should take this long? (I thought monorepos was why you used Bazel, so that would surprise me...) How much of this work will be cached, and how much will have to happen every time I open a component in this monorepo? Will it matter if I've opened that exact component before or not?
The text was updated successfully, but these errors were encountered: