IDEA-originated imports for multi-project builds broken [IDEA 2017.1.5]

[dansanduleac]

I import using IDEA, and all my projects are multi-project builds where only subprojects contain useful code.
By putting all generated code in the rootDir's generated_src (i.e. ../generated_src from a subproject's module root), they don't compile anymore, since they depend on classes only present in the module.

Why aren't we setting the sources directory to ./generated_src from the module's content root? That's always worked for me before.

[alicederyn]

Sample project please. The current system was put in place to make #58 work. (IDEA is a pain.)

As a workaround, try using gradle idea to generate the IntelliJ project, that seems a lot more reliable.

[achacha]

The plugin is changing the settings inside IDEA which is causing problems. You can set that to ./generated_src which works fine from module root, then this plugin runs and resets this setting to ../generated_src and now we have 2 places where the generated code exists and no longer compiles because there is a conflict. How do I tell this plugin to NOT change my IDEA settings?

I can change back inside IDE, go to shell, run a build that invokes this plugin, check the settings and they reverted back to ../generated_src and now the IDE is broken and I have to manually delete the new generated directory in ../../generated_src from project root. It's very annoying to have to constantly change my preferences and delete directories every time command line build is used.

[alicederyn]

That sounds a nightmare. Can you give a sample project so I can work on fixing the plugin?

[achacha]

This is happening inside a very large project, I can't reproduce it in a small project due to the dependencies and project structure. The way you had it working before #58 was working, after that fix my generated code winds up 1 directory higher so my generated_src is outside of the project directory. Is there any way to tell the plugin to not modify settings (a flag maybe) or something to make it work like it did before fix for #58?

[achacha]

As a temporary fix, reverting to version 1.2.8 of the plugin fixes the issue. I am not really comfortable with a command line plugin messing with my IDE settings, but at least now it works as it did before.

[alicederyn]

It's something we need to do to support opening gradle projects directly in IntelliJ, as it runs the gradle files to determine the project setup but doesn't actually trigger any gradle actions :/

[alicederyn]

And I have not come across a way to write integration tests for IntelliJ to properly validate changes.

[achacha]

So the directory setting you are modifying has a radio button which qualifies what that path means:

Store generated sources relative to: Module Output Directory OR Module Content Root

When you set it to ../generated_src and someone has Module Content Root selected the setting you are adding will put generated_src outside of the project root, while Module Output Directory which is commonly 'out' or 'build' will put it correctly into the project root. This may be part of the problem.

[alicederyn]

See #58 for a description of the root cause of the problem.

Which version of IntelliJ are you using?

[achacha]

I am using latest 2017.2.1

I saw the #58 issue but in our case gradle is not integrated into the project, it's mainly a build system so having it modify the IDEA config when it's not the imported configuration breaks things. Can there be a way where we can specify in the gradle.build what you are writing to the generated source or better yet have an option to not update the IDE?

[alicederyn]

So @achacha's issue is now fixed in v1.2.15, but we still need a sample project to fix the original issue described by @dansanduleac 😞

[dwyand]

I've put a repro of the issue up at https://github.com/dwyand/repro-68. @dansanduleac hit the nail on the head with his initial problem statement -- the generated source is simply in the wrong place. Since version 2016.x, the generated source must be under the module directory (src/main). When it is placed at src/generated_src it is considered its own module, and the multi-module package creates pain... in the following, with Model and ImmutableModel are in the same package but different modules, and correctly referencing ImmutableModel would require fully specifying repro68.ImmutableModel:

Is there some reason not to put generated source in the Idea default directories (src/main/generated and src/test/generated_tests)?

My reason for bumping an old issue is that, while I've previously just not used the gradle-processors plugin, I want to get some things upgraded to make use of baseline.error-prone, which depends on gradle-processors. Since gradle-processors affects the whole idea environment, even if the project do not register anything with processor, baseline.error-prone is not currently an option.

For reference, the feature/no-inferred-plugin branch of the repository has what I've previously used to register immutables, which its pretty simple and works with a fully default configuration of Idea... this is the whole thing:

    apply plugin: 'idea'
    idea {
        module {
            sourceDirs += file('src/main/generated')
            generatedSourceDirs += file('src/main/generated')
        }
    }

    dependencies {
        compileOnly group: 'org.immutables', name: 'value', version: immutablesVersion
    }

a note for the repro repository: make sure to close idea and git clean -xdf before importing the gradle project. if idea generates code before this plugin is active, it will go in the right place, and the IDE will find it there and look happy, but it will not be referencing the actual file produced by the immutables processor.

[alicederyn]

When it is placed at src/generated_src it is considered its own module, and the multi-module package creates pain

True, but only if you use IntelliJ's new directory-based structure. If you use the old file-based structure this is not true. I consider this a bug in IntelliJ.

Is there some reason not to put generated source in ...src/main/generated

Yes. Things under src/ are source files, not derived, and one should expect to be able to check in src/ in git without committing generated code. Especially not to work around a bug in an IDE.

I merged the code to work with IDEA's native gradle integration on trust. Having investigated how it's attempting to work, I believe it should be removed. It attempts to modify a file generated by IDEA, racing with it to try and have its changes picked up and integrated, which only works sporadically. The only reliable mechanism for affecting IntelliJ integration is running gradle idea and using the well-thought-out machinery the Gradle designers put in. The native integration offers no such hooks. IntelliJ's designers simply needs to add some. We shouldn't be hacking around their backs.

[dwyand]

The .idea/ directory vs. .ipr file isn't what makes the difference -- its whether or not the gradle plugin generates a project that the IDE imports (which in turn means .ipr only), or if the IDE generates the project itself.

Apart from that, sounds like we might be in agreement -- the plugin is trying too hard to customize something that shouldn't be customized. I think once upon a time idea needed the help, but for more recent version it does a better job without the assist. Not sure avoiding a **/src/main/generated/ in .gitignore is worth IDE pain.

Would a PR that pretty sharply reduces the interaction with idea be welcome? As you mentioned, its tough to test all this beyond "works on my machine" since on changes things within the IDE, so I don't know what validation really needs to go in there.

[alicederyn]

Strange, I thought I'd repro'd the .idea vs .ipr thing at one point. It's been a while though.

Send me the PR and we'll iterate. As long as you don't affect the vanilla gradle idea task :)

[dwyand]

100% believe thats accurate for 2016.x, but I think 2017.x may have changed it.

I think intellij's path forward is really to let the in-IDE automation deal with IDE stuff... that makes sense to me, because none of that affects a command line build anyways, though it is a bit frustrating that its always been available but sort of half-documented and ever changing.

[dwyand]

On a deeper look, going to surrender on trying to simplify the idea end of things 😞.

Didn't realize the name of the generated source was configurable; I think that feature means it definitely has to interact with various bits of idea xml, and I wouldn't propose forcing that to something hardcoded to avoid the xml pain.

womp, womp.