我知道您可以通过 org.gradle.api.Project#getSubprojects()
访问项目中的不同模块(包括使用 include
),我知道您可以通过 org.gradle.api.invocation.Gradle#getIncludedBuilds()
获取已包含(使用 includeBuild
)的独立构建的名称和目录。
但是我的插件如何获取信息,例如使用 includeBuild
包含的项目的 Java 源文件和类文件的位置?
我的目标是确定当前 git 分支中哪些文件发生了变化(我可以做到),然后将它们对应的类文件收集到一个 jar 文件中,该文件用于我们的补丁机制,在前面插入补丁 jar类路径,而不是重新部署整个应用程序。
最佳答案
我不认为 Gradle 的目标是为 including 构建提供关于included 构建的详细信息。目前,Gradle 文档基本上只有 state two goals对于这样的复合构建:
- combine builds that are usually developed independently, […]
- decompose a large multi-project build into smaller, more isolated chunks […]
实际上,所涉及的构建之间的隔离通常似乎是一个重要的主题:
Included builds do not share any configuration with the composite build, or the other included builds. Each included build is configured and executed in isolation.
出于这个原因,让包含构建使用包含构建的任何构建配置(如任务输出)似乎也不可能,甚至也不希望。这只会耦合构建,从而阻碍隔离目标。
包含的构建仅通过 dependency substitution 与其他构建交互:
If any build in the composite has a dependency that can be satisfied by the included build, then that dependency will be replaced by a project dependency on the included build.
因此,如果您想从包含构建中使用包含构建的特定部分,那么您必须执行多项操作:
- 有一个configuration在生成这些“特定部分”作为工件的包含构建中。
- 在包含的构建中有一个配置,该配置将工件作为依赖项使用。
- 确保两种配置都兼容。他们的 capabilities以便依赖替换起作用。
- 让包含构建中的某些任务以您需要的任何方式使用依赖项工件。
当您在两个 Gradle 项目之间存在简单的依赖关系时,这些事情会自动发生,例如 Java 应用程序依赖于 Java 库。但您也可以定义自己的依赖类型。
问题是:这样做真的值得吗?难道您不能更轻松地解决您的目标,或者至少不依赖包含构建的编程检索信息吗?例如:如果您知道包含的构建在 build/classes/java/main
下生成类文件,那么也许只需通过 org.gradle.api.initialization.IncludedBuild#getProjectDir()
从那里获取感兴趣的类。 .
我知道,这可能不是您希望得到的答案。我仍然希望它有用。
关于gradle - Gradle 插件如何访问有关包含构建的信息?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/70626515/