编译，apk项目，编译项目，提供，实现项目之间的Gradle依赖关系区别 [英] Gradle dependencies difference between compile, apk project, compile project,provided,implementation project

问题描述

 编译
 apk项目
编译项目
提供项目
执行
  

我的问题是

编译， apk项目，编译项目，提供的项目在这里？

解决方案

在这里讨论：依赖配置和依赖源。

依赖配置

配置有助于定义依赖的传递性，转而消除必须发现和指定您自己的项目/库所需库的痛苦，包括它们自动。 gradle中的这种配置概念与 Maven's范围：

1. 编译：编译依赖关系可用于所有类路径的项目。而且，这些依赖关系会传播到依赖项目。运行时通常需要编译时依赖。


2. apk ：定义运行时依赖关系。编译时不需要依赖此范围，但它将用于执行。这意味着您可以在编译时节省时间，并且在项目实际运行时仍然可以使用依赖项。 这是一个很好的使用apk依赖项的例子。


3. 提供：这意味着此依赖关系在运行时环境中可用。因此，此范围仅在编译和测试类路径中可用，且不是传递性的。它在Android项目中不受支持，但您可以通过此处所述的定义您自己的配置来解决此问题。

您可以在Android上遇到更多配置，例如 testCompile ，它允许您要指定一个只用于测试的编译时依赖项，假设你想在你的测试中使用junit，那么你应该这样做：

  testCompile'junit：junit：4.12'
  

strong>

了解了可用的配置之后，您需要指定实际的依赖关系。依赖关系可能是内部的或外部的，你可能依赖于你正在处理的另一个库，以及公共可用的库。这就是项目关键字出现的位置，允许您指定对内部模块或库的依赖关系。通过定义一个依赖项作为 compile project ，您将该模块或库添加为您的项目的传递依赖项。假设你有一个项目消息和三个模块（ producer ，消费者和共享），项目结构如下所示：

 消息/ 
 build.gradle 
 settings.gradle 
消费者/ 
 build.gradle 
生产者/ 
 build.gradle 
共享/ 
 build.gradle 
  

现在假设 consumer 和 producer 以json格式存储邮件，并且您要使用 google-gson 。假设这两个项目都有一些它们依赖的通用源代码，您的共享模块。 consumer 的build.gradle可以定义以下依赖项：

 依赖关系{
 //对项目共享的内部依赖项
编译项目（'：shared'）
 
 //对公共可用库的外部依赖项
 // public存储库，如jcenter（）或mavencentral（）
编译'com.google.code.gson：gson：1.7.2'
} 
  配置和源的组合，它使您可以将依赖关系声明为
 
 
 c $ c> compile ，编译项目， apk项目以及更多！
 
Gradle dependencies difference between.
 compile
 apk project 
 compile project
 provided project
 implementation
My questions are

What's the difference between compile ,apk project, compile project,provided project here?
解决方案
There's two separate things to discuss here: Dependency Configurations and Dependency Sources. 

Dependency Configurations

Configurations help define the transitivity of a dependency, which in turn removes the pain of having to discover and specify the libraries your own project/library requires, including them automatically. This notion of configurations in gradle is very similar to that of Maven's scopes:

compile: Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. A compile-time dependency is generally required at runtime.
apk: Defines a runtime dependency. A dependency with this scope will not be required at compile time, but it will be for execution. This means that you can save time while compiling and still have the dependency available when your project actually runs. This is a good example of when to use an apk dependency.
provided: It means that this dependency is available on the runtime environment. As a consequence, this scope is only available on the compilation and test classpath, and is not transitive. It is not supported on Android projects, though you can workaround it by defining your own configuration as discussed here.
There are more configurations that you can encounter on Android, such as testCompile, which allows you to specify a compile-time dependency that will only be used for testing, say you want to use junit in your tests, then you would do as follows: 
testCompile 'junit:junit:4.12'
Dependency Source

Once you understand the configurations available for you, you need to specify an actual dependency. Dependencies might be internal or external, you may rely on another library you are working on, as well as on publicly available libraries. Here's where the project keyword comes in, allowing you to specify a dependency to an internal module or library. By defining a dependency as compile project, you are adding that module or library as a transitive dependency to your project. 

Assume you have a project messages with three modules (producer, consumer and shared), the project structure would look as follows:
messages/
    build.gradle
    settings.gradle
    consumer/
        build.gradle
    producer/
        build.gradle
    shared/
        build.gradle
Now assume that both consumer and producer store messages in json format and that you want to use google-gson for that purpose. Assume that both projects have some common source code that they depend on, your shared module. consumer's build.gradle could then define the following dependencies:
dependencies {
   // Internal dependency to project shared
   compile project (':shared')

   // External dependency to publicly available library, 
   // through public repositories such as jcenter() or mavencentral()
   compile 'com.google.code.gson:gson:1.7.2'
}
To sum up, it is the combination of both configurations and sources that enables you to declare dependencies as compile, compile project, apk project and more!

                        
这篇关于编译，apk项目，编译项目，提供，实现项目之间的Gradle依赖关系区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！