I m having some issues with having IntelliJ play nice with

Question

I m having some issues with having IntelliJ play nice with Since I m using a multi module project I need to set the kotlin scala sources to the preprocessed folder so other modules use the right sources However when re importing the project intelliJ continuously sets the preprocessed folder in build as sources root instead of the normal `src main kotlin` making IntelliJ stop giving hints Is there a way to change the sourcesets in gradle while keeping the source root markings of IntelliJ as they were I have a actually built for something else which has this issue I marked it in TODOs for instance I did an attempt with `idea module ` in `build gradle kts` but that didn t seem to do anything except from giving me duplicate content roots Any tips I was personally thinking I could maybe set the source folders back after building deploying or something but I also couldn t figure out how to do that

Oliver.O · Answer

Seems like you are setting all source directories to the preprocessed folder via `setSrcDirs` erasing the main source directory Would it work if you d just add a source directory like so ```kotlin sourceSets main kotlin srcDir preprocessMain target get ```

Jolan Rensen [JetBrains] · Answer

Thanks for the help I tried that before then you get overloads because classes and functions occur twice in the module according to other modules The preprocessed folder needs to be the only source folder when compiling the project

Oliver.O · Answer

So you d want IntelliJ to see a different set of sources than your compilation In that case wouldn t IntelliJ suffer from multiply defined classes and functions as well

Jolan Rensen [JetBrains] · Answer

yes Well apparently not If I manually unmark the preprocessed folders and mark the normal onces all works fine on the intellij side When running stuff it uses the preprocessed ones and when editing it thinks of the normal folders as source root It s just every time the project gets imported or reloaded the source folders get unmarked again and the preprocessed ones get marked

Oliver.O · Answer

Interesting although I have no idea on how to solve this Maybe there is some way to stop IntelliJ from re importing parts of the Gradle configuration but I don t know unfortunately

Jolan Rensen [JetBrains] · Answer

I think that s where ```idea module ``` should be able to help but I didn t manage to configure that to solve my issue

Oliver.O · Answer

Maybe there is one hack you could try What if you d use a run configuration for compilations set an environment variable there then in the build script specify different sets of source directories depending on whether that environment variable is set compilation=yes import=no

Jolan Rensen [JetBrains] · Answer

Don t think that works because to run a file from IntelliJ it also uses gradle which is needed to make sure it runs preprocessed files I just need to find a way to make what I do manually now marking the directories be done automatically after each run

Oliver.O · Answer

While I have no experience with the `idea` plugin from what I ve read would the `whenMerged` hook help in this case

Jolan Rensen [JetBrains] · Answer

trying that now

Jolan Rensen [JetBrains] · Answer

looks like no iml is being generated at all even when specifying generateTo

Jolan Rensen [JetBrains] · Answer

isn t that a maven thing actually

Oliver.O · Answer

I m just trying to figure out where the IDE stores parts of the imported Gradle configuration in one of my projects

Oliver.O · Answer

Seems like the IDE does not store module configurations in any file just in main memory

Jolan Rensen [JetBrains] · Answer

awesome

Jolan Rensen [JetBrains] · Answer

makes debugging a lot harder

Oliver.O · Answer

Seems like those `beforeMerged` and `whenMerged` hooks don t get called blob shrug

Jolan Rensen [JetBrains] · Answer

explains why my printlns don t do anything

Oliver.O · Answer

Yeah Seems like we have to take this seriously gt The techniques we discuss in this section don t work with IDEA s import facility

Jolan Rensen [JetBrains] · Answer

lol

Jolan Rensen [JetBrains] · Answer

yes apparently indeed

Jolan Rensen [JetBrains] · Answer

I got it It works if you only temporarily change the source sets for the compilation slightly smiling face ```val kotlinMainSources = kotlin sourceSets main get kotlin sourceDirectories val preprocessMain by tasks creating JcpTask class sources set kotlinMainSources clearTarget set true fileExtensions set listOf kt vars set Versions versionMap outputs upToDateWhen false tasks compileKotlin dependsOn preprocessMain doFirst kotlin sourceSets main kotlin setSrcDirs listOf preprocessMain target get doLast kotlin sourceSets main kotlin setSrcDirs kotlinMainSources ```

Jolan Rensen [JetBrains] · Answer

nvm when I now run something from intellij it skips the preprocessing obviously

Oliver.O · Answer

With a toolchain that s unaware of preprocessing I d guess that there is no way to make it work without shooting oneself in the foot now and then I wonder how the final goal could be achieved without preprocessing

Jolan Rensen [JetBrains] · Answer

the only way to do it without preprocessing would be to maintain 14+ source versions

Oliver.O · Answer

Do you have a small example of what you d like to achieve with preprocessing Did you consider using KSP for code generation

Jolan Rensen [JetBrains] · Answer

KSP can only generate code not modify it right Plus my project has both scala and kotlin Here is an example for why code generation is necessary On some versions you need an override on others not It could only work with ksp if you d generate this entire file in it Other compatibility issues I have are like this where `DayTimeIntervalType ` just doesn t yet exist before spark 3 2 so I cannot reference it using a normal if statement it needs to be actually removed from the code Same story if you d want to autogenerate it it s a 1400+ lines file

Jolan Rensen [JetBrains] · Answer

```tasks compileKotlin dependsOn preprocessMain outputs upToDateWhen false ``` seems do do something

Jolan Rensen [JetBrains] · Answer

obviously it becomes slow but at least it works

Oliver.O · Answer

You are right in that KSP cannot modify code You d need a compiler plugin for that Also while KSP cannot process Scala it could generate Scala code although it would currently lack a proper output directory for that as far as I remember I ll take a look at your code examples

Jolan Rensen [JetBrains] · Answer

the outputs upToDateWhen seems to do the trick for now I m making it depend on ```preprocessMain outputs upToDateSpec this ``` and in preprocessedMain I m trying to create a file listener or something so that the preprocessing detects correctly it s time to run

Oliver.O · Answer

Seems a bit on the edge but pragmatism sometimes is fingers crossed It s probably hard to support a multitude of Spark library versions from a single code base +1

Jolan Rensen [JetBrains] · Answer

actually that is super easy barely an inconvenience Mostly it s just changing the versions in gradle to get bytecode compatibilty After that it s just removing a couple of encoders Same with supporting multiple scala versions

Oliver.O · Answer

Yeah that s the easy part but then your toolchain has no idea about that preprocessing step and thus cannot reason about its implications

Jolan Rensen [JetBrains] · Answer

that s why I need to keep the preprocessing to a minimum and have loads of tests slightly smiling face

Jolan Rensen [JetBrains] · Answer

we also test for all version on GH actions

Jolan Rensen [JetBrains] · Answer

```tasks compileKotlin dependsOn preprocessMain outputs upToDateWhen preprocessMain outcomingFiles files isEmpty ``` seems to do the trick JCP has outcoming files when there were changes anywhere in your given source folders IntelliJ also always listens to upToDateWhen slightly smiling face