Gradle dependency (dependency) configuration

 Dependency configurations (dependency configurations), or dependencies, the Java plugin dependency management in Gradle is the part that must be understood. There are a few common ones:

The compile
project needs the content of these dependent libraries at the compile stage, which includes the sub-dependencies of the dependent libraries, and these content will eventually be added to the classpath. For example, Spring and Hibernate's dependent libraries.

Runtime
inherits compile. These dependent libraries are needed when the project is executed. For example, the dependency library of MySQL driver. Remarks: Suppose the project uses a dependency A, and A is dependent on B?, only A is needed in the compilation phase of the project, but A and B are actually needed in the execution phase. This is why the dependencies of the configuration compile can be seen by the runtime, but the reverse Not necessarily correct.

compileOnly
inherits compile. These dependent libraries are basically only used during the project compilation phase, and are not used during the project execution phase. These content will not be added to the runtime classpath in the end. Like source-only annotations. Simply put, it is possible that the version of the dependent library used during compilation is different from the one during execution, such as com.android.support. If only compile is used, a version error conflict may occur during execution.

There will also be some changes in IDEs that support Gradle. For example: Account.java needs to be in the A-dependent library, and this Account category will be used in the main execution logic of the project, then the IDE will first jump the red letter (prompt error) because of this Fashion did not introduce A-dependent libraries. If the compile configuration is used at this time, the red letter disappears and the execution is normal. If you use compileOnly configuration, the red letter disappears, but the execution fails. If you use runtime configuration, the red letter is still there and cannot be executed. Compile is the best choice at this time.

Suppose that the context changes to need to reference Share.java, which does not appear in our program, but this category will be used during execution, then if the compile configuration is used at this time, basically the IDE will not appear in red at all, execute Will succeed. If it is configured with runtime, it will execute successfully. The compileOnly configuration will fail, because the dependent library of this configuration will not appear in the runtime classpath, and the category will naturally not be found during execution. The runtime is most suitable in this example.

In the last scenario, an interface of Shape.java is used on the IDE, but the implementation content of Shape is not implemented by us, but will be provided according to the jar file of the environment or other dependent execution stages, then At this time, if the compile configuration is used, the red letter will disappear, and the execution may fail due to the lack of implementation during execution. With runtime configuration, the red letter is present and cannot be executed. With compileOnly configuration, the red letter will disappear, and the implementation may fail due to not being found during execution. The results of compile and compileOnly are the same, but because the result of the distinction is that the compilation will succeed, but the execution still may not find the implementation dependency and fail. This type of dependency library is the most suitable choice for compileOnly.

When using the java plugin, you will basically see two source sources, src/main/java and src/test/java. The above three dependent configurations are mainly applied at the bottom of the main layer, and the configurations with prefix test such as testCompile, testRuntime, and testCompileOnly are actually similar, but they are the content of the layer where the test is applied. This configuration is normal and reasonable, because the main program and the test program should not be co-located. For example, a common dependent library that will only be used during test: JUnit.

Another thing that is often confused is the two new configurations providedCompile and providedRuntime in the war plugin. The two meanings with the prefix provided- mainly mean that the final content in the classes will not be packaged into the war file. This is very important, because some dependent libraries exist for the convenience of the development phase, and may not be needed due to different environments during deployment. For example, embeded tomcat, dev tools, etc.

Finally, there is another java-library plugin, which has more configurations such as api, implementation, runtimeOnly, which can be used for more detailed control, please refer to Gradle official website.

Understanding the above common configurations, clarifying which dependent configurations belong to which plugin, and understanding which configuration is more suitable under what circumstances, will no longer just use compile all the way to the end. Good habits will help in setting up the environment, debugging dependencies, or information security during deployment. It can also save a lot of unnecessary mistakes, or solve a lot of unnecessary concerns. The scarlet letter, especially when the team develops a mature product, this is very necessary.