bazelbuild
Override Reload File debugger action
Checklist
- [ ] I have filed an issue about this change and discussed potential changes with the maintainers.
- [ ] I have received the approval from the maintainers to make this change.
- [ ] This is not a stylistic, refactoring, or cleanup change.
Please note that the maintainers will not be reviewing this change until all checkboxes are ticked. See the Contributions section in the README for more details.
Description of this change
Currently, IJ has a "Compile and Reload file" option available via right clicking the contents of a java file. This is currently broken with Bazel since the action needs to be overridden to delegate to bazel build. This work aims to implement a similar functionality via overriding the action, delegating to bazel build, and finding and extracting the compiled classes to pass hotswap.
I'm not sure if it is possible to reuse the logic of BlazeHotSwapActionManager to reload the certain file of interest in BlazeReloadFileAction.java
I'm not sure if it is possible to reuse the logic of BlazeHotSwapActionManager to reload the certain file of interest in BlazeReloadFileAction.java
I did look at this code initially, unfortunately not without a lot of refactoring (which I could do, just decided it would not be a lot of overlapping code to consider it).
The current manager has a tight coupling to the ClassFileManifest which does not work for our case (where bazel run is run outside the IDE and we are attaching to the instance). Because of this (and other fun our app launcher works), the ClassFileManifest does not work. Because of this, the route I took with this PR is to only compile and hotswap a single file. Since we know the file, we do not need to use the ClassFileManifest.
Let me know if I missed something or if you believe refactoring would still be useful and Ill take a closer look :) .
@mai93 checking back on this. Any thoughts or concerns with this getting merged?
Sorry for the delay! I do not think I will have the time to review this, @tpasternak offered to take a look next week.
Doesn't work for me.
I tested it on Linux by running the
getPendingExternalDeps_followJavaDeps_allBuilttest from this repo. I placed a breakpoint inside it and clickedCompile and reload file.The
building targetsprogress indicator seems to be stuck forever. Looks like we're deadlocking Bazel.
Build waits for the test to finish, but it was started because I requested a rebuild from inside the test...
Does it look like https://github.com/bazelbuild/bazel/issues/2337 ?
Does it look like bazelbuild/bazel#2337 ?
I'm not sure what you mean. I don't run anything in the command line manually. What I did was (I guess?) your expected workflow with this feature.
Does it look like bazelbuild/bazel#2337 ?
I'm not sure what you mean. I don't run anything in the command line manually. What I did was (I guess?) your expected workflow with this feature.
@agluszak was taking a look at this yesterday, as far as I could tell the original hotswap implementation is also not supported when running tests via bazel. Seems like bazel run does not lock the server, but bazel test does. That said, I did not intend to replace the original hotswap mechanism, simply provide another option when not using launching the bazel target through the debug profile. It was intended for remote debugging. Either way, I'll update the logic to disable this action when the debug session is from a bazel target. In addition ill address the cancelation exception you discovered.
Pushed a commit to add extra handling for the case of unsynced files. Was noticing the action was still available even when the file was unsynced. I also found that there was an exception for slow tasks in the UI thread, I have to override getActionUpdateThread to allow the BGT thread to be used, which the original action was using.