api配置暴露了缺陷，而实现却不暴露，这到底意味着什么？

Question

我已经看过了官方文档和许多关于API和implementation配置之间区别的StackOverflow问题。我想我理解基本的，但我真的想理解依赖项暴露或不暴露意味着什么。

这就是我目前所得到的。当我发布我的Java库（用Kotlin编写，但不相关）时，发布的POM文件中的依赖范围要么是使用API时的complie要么是使用implementation时的runtime。

dependencies {
    api "..."
}
<dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
      <scope>compile</scope> 
</dependency>

dependencies {
    implementation "..."
}
<dependency>
      <groupId>...</groupId>
      <artifactId>...</artifactId>
      <version>...</version>
      <scope>runtime</scope> 
</dependency>

那么在这种情况下公开依赖项真的只是意味着将它们添加到类路径（编译范围）吗？

关于API和implementation的许多答案之一是，它仅仅是关于构建优化，如果我们不在类路径中添加所有内容，那么构建时间就会减少，这是有道理的？

还有一个额外的问题，Gradle doc说API配置附带了java-library插件，但显然，我可以在不应用插件的情况下使用它，这怎么可能呢？

// Gradle 6.1.1
plugins {
    id 'org.jetbrains.kotlin.jvm' version 'XXX'
}
dependencies {
    api "myLibrary"
}

Answer 1

那么在这种情况下公开依赖项真的只是意味着将它们添加到类路径（编译范围）吗？

是的，这很大程度上只是在使用者的compile类路径上有没有它们的问题。

关于api vs实现的许多答案中有一个说它只是关于构建优化，如果我们不在类路径中添加所有内容，那么构建时间就会减少，这是有道理的？

null

最后一个在我看来是最大的好处。假设您有一个大型多项目，其中一个共享子项目内部依赖于Apache Commons Lang。如果您已经将Lang声明为api依赖项并对其进行了更新，那么所有其他依赖于此共享项目的项目都需要重新编译。如果您将其声明为实现依赖项，则不会发生这种情况。所有这些项目仍然需要重新进行原因测试，因为运行时行为可能已经发生了变化（在Gradle中，这是默认情况下正确处理的）。

还有一个额外的问题，Gradle文档说api配置随java-library插件而来，但显然，我可以不应用插件就使用它，这怎么可能呢？

这是因为Kotlin插件还声明了一个api配置。它具有与java-library插件配置的相同的语义。