'Provided' dependency in Gradle

58.8k views Asked by At

I have build.gradle in front of me and there are some dependencies declared as provided but in documentation I do not see this dependency scope.

dependencies {
    compile("org.springframework.boot:spring-boot-starter-web:1.2.4.RELEASE")
    ....

    provided 'backport-util-concurrent:backport-util-concurrent:3.1'
    provided 'org.javolution:javolution:5.5.1@jar
    ....
}

Is this provided by a plugin? If so how do I found out which plugin this belongs to?

What is the difference between provided and runtime dependency scope in Gradle?

4

There are 4 answers

4
Sazzadur Rahaman On BEST ANSWER

What is provided scope?

Suppose that a jar is needed to compile your code, but the jar is present in the production environment library collection. Then you don't need to package the jar with your project archives. To support this requirement, Maven has a scope named provided. If you declare any jar dependency as provided, then this jar will be present in your classpath during compilation but will not be packaged with your project archive.

provided scope is very useful, particularly in web applications. For example, servlet-api.jar is needed to be present in your classpath to compile your project, but you don't need this to package servlet-api.jar file with your war. With provided scope one can achieve this requirement.

There is no Scope defined in Gradle java plugin named provided. Also not in war or android plugins. If you want to use provided scope in your project, then you have to define it in your build.gradle file. Following is the code snippet to declare provided scope in gradle:

configurations {
    provided
}

sourceSets {
    main { compileClasspath += configurations.provided }
}

Now, your second question:

What is the difference between provided and runtime dependency scope in Gradle?

To answer this question first I will define compile dependency. compile dependencies are dependencies, those are necessary to compile your code. Now imagine that if your code uses a library named X then you must declare X as your compile-time dependency. Also imagine that X uses another library Y internally, and you declared Y as your runtime dependency.

During compilation, Gradle will add X into your classpath but will not add Y. Since, Y is not required for compilation. But it will package both X and Y with your project archive since both X and Y are necessary to run your project archive in the production environment. Generally, all the dependencies needed in the production environment are known as runtime dependency.

In Gradle official documentation, it says that runtime dependency are "the dependencies required by the production classes at runtime. By default, also includes the compile time dependencies.".

Now, if you've read this far, then you already know that provided is a compile dependency that we don't want to be present in the runtime dependency (basically, we don't want it to package with the project archive).

Following is an illustration of provided and runtime scope. Here, compile refers to the dependencies that are required to compile the project and non-compile refers to the dependencies that are not required for project compilation.

0
KnockingHeads On

Updating the answer as per the latest gradle versions.

From gradle's official documentation at below link:

https://docs.gradle.org/current/userguide/upgrading_version_5.html

Deprecations

Dependencies should no longer be declared using the compile and runtime configurations. The usage of the compile and runtime configurations in the Java ecosystem plugins has been discouraged since Gradle 3.4.

The implementation, api, compileOnly and runtimeOnly configurations should be used to declare dependencies and the compileClasspath and runtimeClasspath configurations to resolve dependencies.

More so, the compile dependency configuration has been removed in the recently released Gradle 7.0 version.

If you try to use compile in your Gradle 3.4+ project you’ll get a warning like this:

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0. Use ‘–warning-mode all’ to show the individual deprecation warnings.

You should always use implementation rather than compile for dependencies, and use runtimeOnly instead of runtime.

War plugin

The War plugin extends the Java plugin to add support for assembling web application WAR files. It disables the default JAR archive generation of the Java plugin and adds a default WAR archive task.

The War plugin adds two dependency configurations:

  1. providedCompile
  2. providedRuntime

Adding an entry to providedCompile or providedRuntime will cause that dependency to be excluded from the war file.

  1. Use providedCompile if you have source that relies on some classes for compiling.
  2. Use providedRuntime if you use it for testing and not compiling.

Example:

providedCompile 'org.springframework.boot:spring-boot-starter-tomcat:1.1.6.RELEASE'

The above JAR and its transitive dependency will only be available at compile time but it will not be available at runtime. It means, those JAR will not be included in war archive.

3
gagarwa On

For further clarification, as of the latest version, Gradle 5.5 has compileOnly (same as provided) and runtimeOnly options. The new default "compile and runtime" option is implementation.

2
PaulNUK On

As from Gradle 2.12, you can use the compileOnly option.

See

https://blog.gradle.org/introducing-compile-only-dependencies