在Gradle中实现和编译有什么区别 [英] What's the difference between implementation and compile in gradle

问题描述

在更新到Android Studio 3.0并创建一个新项目后，我发现在 build.gradle 中有一种新方法来添加新的依赖项，而不是 compile 有实现，而不是 testCompile 有 testImplementation 。

示例：

  implementation'com.android.support:appcompat-v7:25.0.0'
 testImplementation'junit：junit：4.12'
  

而不是

  compile'c​​om.android.support:appcompat-v7:25.0.0' 
 testCompile'junit：junit：4.12'
  

它们之间的区别是什么？使用？

解决方案

这是Gradle 3.0中的一个突破：Google 在IO17宣布 gradle：3.0

编译配置为现在已被弃用，应该由实现或 api

从 gradle docs ：

  dependencies {
 api'commons-httpclient：commons-httpclient：3.1'
 implementation'org.apache.commons：commons-lang3：3.5'
} 
  

在 api 配置中出现的依赖关系将为
传递给图书馆的消费者，因此
会出现在消费者的编译类路径中。

在
配置中的实现配置中找到的依赖关系不会暴露给消费者，因此不会泄漏到
消费者的编译类路径中。这带来了一些好处：

• 依赖不会泄漏到消费者的编译类路径中，因此您不会意外地依赖于可传递的
  依赖关系
  
• 由于减少了类路径的大小，所以编译速度更快
  
• 实现依赖关系发生变化时重新编译的次数更少：消费者不需要重新编译
>

• 更清晰的发布：当与新的maven-publish插件一起使用时，Java库会生成POM文件，
  区分
  库中需要编译的内容和需要在运行时使用库（以其他
  字样，不要混合编译库本身所需的内容以及需要
  来编译库）。

编译配置仍然存在，但不应该使用，因为它不会提供api和实现配置tions提供。

---

tl; dr

只需替换：

• compile code> with implementation


• testCompile with testImplementation


• debugCompile with debugImplementation


• androidTestCompile with androidTestImplementation


• compileOnly 仍然有效。它被添加到3.0来替换提供的而不是编译。 （>提供>当Gradle没有该用例的配置名称时引入并在Maven的提供的作用域中将其命名）。


>

After updating to Android Studio 3.0 and creating a new project, I noticed that in build.gradle there is a new way to add new dependencies instead of compile there is implementation and instead of testCompile there is testImplementation.

example:

 implementation 'com.android.support:appcompat-v7:25.0.0'
 testImplementation 'junit:junit:4.12'

instead of

 compile 'com.android.support:appcompat-v7:25.0.0'
 testCompile 'junit:junit:4.12'

What's the difference between them and what should I be using?

解决方案

It is one of the breaking changes coming with gradle:3.0 that Google announced at IO17 gradle:3.0

the compile configuration is now deprecated and should be replaced by implementation or api

From the gradle docs :

dependencies {
    api 'commons-httpclient:commons-httpclient:3.1'
    implementation 'org.apache.commons:commons-lang3:3.5' 
}

Dependencies appearing in the api configurations will be transitively exposed to consumers of the library, and as such will appear on the compile classpath of consumers.

Dependencies found in the implementation configuration will, on the other hand, not be exposed to consumers, and therefore not leak into the consumers' compile classpath. This comes with several benefits:

• dependencies do not leak into the compile classpath of consumers anymore, so you will never accidentally depend on a transitive dependency
• faster compilation thanks to reduced classpath size
• less recompilations when implementation dependencies change: consumers would not need to be recompiled
• cleaner publishing: when used in conjunction with the new maven-publish plugin, Java libraries produce POM files that distinguish exactly between what is required to compile against the library and what is required to use the library at runtime (in other words, don't mix what is needed to compile the library itself and what is needed to compile against the library).

The compile configuration still exists but should not be used as it will not offer the guarantees that the api and implementation configurations provide.

---

tl;dr

Just replace:

• compile with implementation
• testCompile with testImplementation
• debugCompile with debugImplementation
• androidTestCompile with androidTestImplementation
• compileOnly is still valid. It was added in 3.0 to replace provided and not compile. (provided introduced when Gradle didn't have a configuration name for that use-case and named it after Maven's provided scope.)

这篇关于在Gradle中实现和编译有什么区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！