IntelliJ IDEA 2017.3 EAP brings improvements for unloaded modules
The latest IntelliJ IDEA 2017.3 EAP build brings lots of new features, and now it’s time to take a look at the improvements for unloaded modules.
In IntelliJ IDEA 2017.2 we announced an experimental feature called Load/Unload Modules. This feature allows you to unload unnecessary temporary modules from your project. The Load/Unload Modules feature is especially useful for managing modules in large projects.
Until now, however, if you updated via a VCS, all newly added modules were marked as loaded by default. This was not very convenient and in some cases could even lead to compilation failures.
Initially, the project only had only three modules: pluginA, pluginB and platform. Let’s assume you’re currently working on pluginA. Because it depends on platform, you marked these two as loaded modules, while pluginB stays unloaded. Then a colleague adds pluginC and util to the project and you get these modules from your VCS. Platform depends on util, and pluginC depends on platform.
Previously, the IDE marked all newly added modules as loaded. But starting with this new EAP, IntelliJ IDEA will analyze all added modules. In the example above, only util will be treated as a loaded module, and pluginC will stay unloaded.
IntelliJ IDEA 2017.3 will alert you to this:
Another new enhancement in this area is a сheck for unloaded modules to compile successfully before a commit.
In most cases, IntelliJ IDEA detects possible problems and alerts you to them. Invoke a refactoring on some element from platform, and the IDE will show a warning if this change affects unloaded modules. Still, there are situations when you can easily break compilation for unloaded modules without even noticing it.
Back to our example, pluginB depends on platform. If you write a new method in an interface in platform and this interface is implemented in pluginB, compilation for unloaded plugin B will fail when you load it back. Previously, the IDE didn’t detect a potential problem, even though committing such changes could break the compilation of the whole project.
In this EAP, we have resolved this issue by adding an option called ‘compile affected unloaded modules’ to the ‘Commit Changes‘ dialog. This option triggers the compilation of unloaded modules if a commit includes changes that affect modules that depend on unloaded ones.