Adding ability to safely enable/disable module fragments (requires restart, obviously), and tweaking nbjavac so that it can be enable/disabled. #6743
Conversation
…start, obviously), and tweaking nbjavac so that it can be enable/disabled.
lahodaj
added
Java
| @@ -87,6 +91,11 @@ public static boolean hasModulesForDisable (File updateDir) { | |||
| return deactivateDir.exists () && deactivateDir.isDirectory () && Arrays.asList (deactivateDir.list ()).contains (TO_DISABLE); | |||
| } | |||
|
|
|||
| public static boolean hasModulesForEnable (File updateDir) { | |||
| File deactivateDir = new File (updateDir, UpdaterDispatcher.DEACTIVATE_DIR); | |||
There was a problem hiding this comment.
Nitpick: having enable file in deactivate directory is a bit awkward...
| new ModuleDeactivator(context).enableDisable(false); | ||
| } | ||
|
|
||
| // then disable |
|
@neilcsmith-net thanks! FWIW, I think we can (and should) defer this to NB 22, so that if something is broken, we can fix before the release. I'd like to merge soon after branching. Please let me know if there are any issues with this. |
|
@lahodaj I wouldn't have rushed to release the Windows launchers this week in that case! 😕 Either we merge this or revert that imo. |
|
Uh. Sorry, I thought you were doing the launchers anyway, and I just went along. And got a bit scared. Will merge this then. |
|
No, the launcher source was moved back, but I only ran a release to get your change in. There are some other changes discussed, but not yet made, that would be good to get into NB22. If for any reason the launcher update isn't required for this then the safer option would be (would have been) to keep the existing binaries for NB21. Let's test with 21-rc1, and if any issues emerge, we can always revert both changes and push back to NB22. |
|
@lahodaj I think this is the cause of a regression that causes a lockup in ergonomics. See #7091 As I mention in the long comment there, one option seems to be to revert the removal of the recommends in java.source.base. But I assume that is necessary here? Other option might be to find a way to force loading of full Java kit in ergonomics instead of just extide? |
Currently,
libs.nbjavacapi(which is a module fragment forlibs.javacapi) cannot be simply deactivated, it must be uninstalled to be really not used.This patch is attempting to fix that, by:
a) following enabled/disabled for module fragments (rather then using them regardless of their status)
b) tweaking (or fixing)
ModuleManager.simulateEnableto not fail if the fragment host is already enabled (so that the list of modules to enable is available).enablewill fail, of course, if the fragment host is already enabled. This is needed so that the UI can check which modules would be enabled, and force a restart if/as needed.c) tweaking the UI so that it can force a restart also when enabling modules (it already does that when disabling modules). Sadly, this requires quite a few changes, including adding a new on-disk file for the enable list.
As this adds a
to_enable.txtfile, this will also need a change in the Window launchers. Alternatively, we could re-purpose theto_disable.txtfile, by using it also for module enablement (which could be done e.g. creating sections in that file).Please let me know what you think. I am not that much expert on the module system. Thanks!
^Add meaningful description above
By opening a pull request you confirm that, unless explicitly stated otherwise, the changes -
Please make sure (eg.
git log) that all commits have a valid name and email address for you in the Author field.If you're a first time contributor, see the Contributing guidelines for more information.
If you're a committer, please label the PR before pressing "Create pull request" so that the right test jobs can run.