Provided dependencies with Spring Boot, the War plugin and IntelliJ Idea

Hi,

I’m using the combination of the spring-boot, the war and the idea plugin. I’m building a deployable .war file (instead of an executable one), as described in the Spring Boot user guide. This means that I add the embedded tomcat of spring boot to the providedRuntime configuration.

The problem is: the providedRuntime configuration is always added to the PROVIDED scope of the Idea module, and therefore excluded from the runtime classpath, and this does (of course) not work. But I can’t seem to be able to change that.

With:

        idea {
        module {
            scopes.COMPILE.plus << configurations.providedRuntime
        }
    }

the dependencies are still added to the PROVIDED scope.

With:

    idea {
        module {
            scopes.COMPILE.plus << configurations.providedRuntime
            scopes.PROVIDED.minus << configurations.providedRuntime
        }
    }

the dependencies are not added to the module at all. I can’t even find (anywhere in the plugin sources) where or why the providedRuntime configuration (that’s added by the war plugin) is configured to be added to idea’s PROVIDED scope.

Any ideas on how to solve that?

Could you provide some context as to how you are deploying the WAR during development? If you are creating a regular WAR aren’t you deploying it in a servlet container which would provide the required runtime libraries?

We use Spring Boot main class directly in Idea during development, and war files for deployment (to several environments).

To make this clear: the war file works fine, executing the application with grade (spring boot plugin’s bootRun task) also works fine, only the scope mapping for Idea is undesirable.
What I logically want: apply the “provided” semantic for the war file, but treat running in Idea like a compile or test run where the provided libraries are included. The spring boot plugin treats the bootRun task exactly like this.

@Rainer_Frey Did you ever figure out how to make this work?

Not really … we have two workarounds:

  • start the application from gradle (inside IDEA)
  • run a sed command over the IDEA module files (these are the only provided dependencies in our project, so we can just search for PROVIDED)

Yea, I have been just running bootRun from within IDEA, however the startup takes a little longer and you don’t get the pretty colors :slight_smile:

I’ll try out the sed approach for now, but to be properly fixed I’m guessing JetBrains this will have to handle this scenario in IDEA.

I noticed removing the dependencies from PROVIDED works, but adding to COMPILE does not. I guess that does seem like a bug with the Gradle Idea plugin.

@mark_vieira If we add items to the scopes.COMPILE from the providedRuntime configuration shouldn’t they be added in the resulting .iml file? Should a bug be opened? Thanks!

Here’s a workaround that goes the opposite way: Keep the dependencies in compile configuration (IntelliJ maps them correctly to “Compile” scope), but prevent them from being added to the WAR lib folder. Instead they are put in lib-provided as with providedRuntime configuration.

    configurations {
        customProvidedRuntime
    }

    dependencies {
        compile(
            // Spring Boot dependencies
        )

        customProvidedRuntime('org.springframework.boot:spring-boot-starter-tomcat')
    }

    war {
        classpath = files(configurations.runtime.minus(configurations.customProvidedRuntime))
    }

    springBoot {
        providedConfiguration = "customProvidedRuntime"
    }
1 Like

I’ve run into this issue as well. I tried manually changing the provided to compile in the IntelliJ dependencies without changing my build.gradle file. It worked until IntelliJ synced back up with the Gradle file.

Is this is a bug? Has anyone posted this issue with Jetbrains?

Man, you awser is THE right one, you saved my life!

Actually, I made it work with only:

configurations {
customProvidedRuntime
}

customProvidedRuntime (‘org.springframework.boot:spring-boot-starter-tomcat’)

If this worked for you then that means you never needed that dependency. You haven’t wired the customProvidedRuntime configuration anywhere, so it will never be used.

1 Like