My question is a little bit common, but it is linked with Gradle too.
Why we need compile and runtime configuration?
When I compile something I need artifacts to convert my java classes in bytecode so I need compile configuration, but why is needed runtime configuration do I need something else to run my application in JVM?
Sorry if it sounds stupid, but I don't understand.
Rule 1: you should always use implementation rather than compile for dependencies, as compile is now deprecated or removed in Gradle 7+. Also bear in mind: Rule two: use the implementation dependency configuration if you need the dependency to be on both the compile and runtime classpaths.
compile is the group of dependencies you need to build your application while testCompile is a group of dependencies that you need only for testing. This specifies that hibernate-core is needed to build your code but junit (a testing framework) is needed just for testing.
Dependencies refer to the things that supports in building your project, such as required JAR file from other projects and external JARs like JDBC JAR or Eh-cache JAR in the class path. Publications means the outcomes of the project, such as test class files, build files and war files.
A “configuration” is a named grouping of dependencies. A Gradle build can have zero or more of them. A “repository” is a source of dependencies. Dependencies are often declared via identifying attributes, and given these attributes, Gradle knows how to find a dependency in a repository.
In the most common case, the artifacts needed at compile time are a subset of those needed at runtime. For example, let's say that a program called app
uses library foo
, and library foo
internally uses library bar
. Then only foo
is needed to compile app
, but both foo
and bar
are needed to run it. This is why by default, everything that you put on Gradle's compile
configuration is also visible on its runtime
configuration, but the opposite isn't true.
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.
What is an implementation dependency?
When you’re building and running a Java project there are two classpaths involved:
Compile classpath – Those dependencies which are required for the JDK to be able to compile Java code into .class files.
Runtime classpath – Those dependencies which are required to actually run the compiled Java code.
When we’re configuring Gradle dependencies all we’re really doing is configuring which dependencies should appear on which classpath. Given there are only two classpaths, it makes sense that we have three options to declare our dependencies.
Use the implementation dependency configuration if you need the dependency to be on both the compile and runtime classpaths. If not, consider compileOnly or runtimeOnly.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With