Problems with run/debug configuration in complex multi-module Gradle project where source dir is shared across several modules

Answered

We have a large multi-module Gradle project where our core Java product has several variant ‘editions’ (open-source, commercial - that kind of distinction). We have been using a very complex gradle build to manage this, and have been experimenting with a different approach, using per-edition gradle subprojects, instead of a single project. This allows us to massively simplify some aspects of the build. Each edition's gradle subproject uses different configurations of `java-comment-preprocessor` to generate sources from a single `src` directory, which are used as the inputs into gradle's Java tooling. It works very well from the command line.

We use IDEA as our IDE, and where we have problems is with debug and run configurations. After freshly opening the project and importing the gradle model into IDEA, it's not possible to run or debug tests, or debug classes, without tweaking the module settings, and the debugger also drops you into the generated source files, not the actual source files, once you're stepping through. You can make further tweaks to the project modules configuration to get that to work, but the changes are ephemeral, disappearing if you re-sync the gradle project. They're also incomplete - you can't make the changes to more than one edition or the changes cannot be applied because of duplicate content roots.

I've created a simplified version of the project at https://github.com/Saxonica/shared-source-intellij-project so people can see exactly what I'm talking about.

From the README for that repo, our problems can be summarised as:

  • The IntelliJ module configuration picked up from the Gradle project does not correctly find the source, or test, classes.
  • The use of a source preprocessor requires manual tweaking of the module config so that the debugger shows the correct source file (i.e. the original file, not the generated source under build/).
  • If a module configuration is manually tweaked in the IDE to get the debug/run configurations to work correctly, re-syncing the Gradle project wipes those tweaks out.
  • If one of the Gradle subprojects is manually configured so that the debug/run configurations work correctly, those configuration changes have to be erased before one of the other subprojects can be configured otherwise you can't set up the other subprojects because of 'duplicate content root' errors.
  • If 'Generate .iml files for gradle projects' is checked, and the content root tweaks required made, the settings will be persisted in a .iml file, but that file will be deleted when the gradle project is re-synced.

This project is simplified from the project we're having problems with, where different editions (ee and he here) have slightly different filtered selections of the source files, different preprocessor options, and different library dependencies.

We're doing all our building by invoking Gradle from the command line, so we're not bothered by this except when trying to debug.

What I need help with is making it possible to reliably invoke the debugger without a load of error-prone manual tweaks that have to be repeated at irregular intervals.

Thanks!

0
2 comments

Hello, Matt!

Thank you for reporting this!

This appears to be a rather advanced Project configuration, that IDEA does not interpret correctly.

I've created YouTrack Issue IDEA-367033 for it and assigned it to the developers, so they can look into implementing support for this kind of Project configurations.

Keep an eye on IDEA-367033 for further updates!

0

Matt Patterson I've got feedback from the developers on this and the issue is multilayered.

One part of it as that IDEA currently does not shared source directories (Content Roots), but we are working on implementing it.

Another part is issue with the Project configuration: incorrect paths to the test source directories: "../../src/test/java" instead of "../src/test/java". 

Source directories, set via the preprocessor, are identified correctly, once they are created:

0

Please sign in to leave a comment.