ComposingBuilds缺点补充 about composingbuilds-vs-buildsrc HOT 48 OPEN

我在用的，AS4.2preview支持的。

from composingbuilds-vs-buildsrc.

composingBuilds怎么检测依赖更新呢

通过插件 Gradle Versions Plugin，可以查看另外一个项目 PokemonGo ，搜索 如何检查依赖库的版本更新

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle

如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

可以看我这个回答：#4 (comment)

from composingbuilds-vs-buildsrc.

嗯嗯，目前来说，ComposingBuilds 确实有这个问题

from composingbuilds-vs-buildsrc.

@Young-Joe 赞呢， @faithlove 我在试了一下，在 AS4.2preview 上已经支持跳转了

from composingbuilds-vs-buildsrc.

我在用的，AS4.2preview支持的。

大佬，请问有使用 ComposingBuilds 的开源项目推荐吗

from composingbuilds-vs-buildsrc.

@Terry999555

可以参考我另外一个项目 AndroidX-Jetpack-Practice 这个项目 基于 Composing builds 开发的自定义插件，作为整个仓库的依赖库的版本管理，使用 Composing builds 作为依赖库的版本管理

from composingbuilds-vs-buildsrc.

@Young-Joe 赞呢， @faithlove 我在试了一下，在 AS4.2preview 上已经支持跳转了

啊，我这用4.2 Beta2试了还是不行😢

from composingbuilds-vs-buildsrc.

@Young-Joe 赞呢， @faithlove 我在试了一下，在 AS4.2preview 上已经支持跳转了

啊，我这用4.2 Beta2试了还是不行😢

Beta 我还没有更新，在 preview 上支持，那么在 Beta 版本 上也支持， 是不是在使用方式不对，

• 从 App Moulde 中点击引用 lib 之后会跳转到对应的 lib
• 然后点击跳转过去的 lib ， 也能够跳转到 App Moulde

from composingbuilds-vs-buildsrc.

为什么编译的时候会有2个进程 build running呀

from composingbuilds-vs-buildsrc.

@ailiboy520 编译？？？ 是首次打开 AS , 还是点击 sync project with gradle 开始编译？

我的理解应该是你看的底部两个进度条，一个是更新的进度条，一个是编译的进度条

from composingbuilds-vs-buildsrc.

似乎不支持gralde的模块化配置，请问有什么解决方案么

from composingbuilds-vs-buildsrc.

@zhubiaozhi 模块化配置 可以参考我另外一个项目 AndroidX-Jetpack-Practice

from composingbuilds-vs-buildsrc.

@zhubiaozhi 模块化配置 可以参考我另外一个项目 AndroidX-Jetpack-Practice

没看到有处理这种类型的案例 比如：apply from: rootProject.file('script/plugin_lib_common.gradle')

from composingbuilds-vs-buildsrc.

@zhubiaozhi 模块化配置 可以参考我另外一个项目 AndroidX-Jetpack-Practice

没看到有处理这种类型的案例 比如：apply from: rootProject.file('script/plugin_lib_common.gradle')

关于 apply from 的用法，可以看一下这篇文章
https://www.jianshu.com/p/99ab352be5b1

from composingbuilds-vs-buildsrc.

编译和运行都没问题，cleanbuild会报错，If this is an unrelated build, it must have its own settings file. 但是可以正常编译完成。

from composingbuilds-vs-buildsrc.

编译和运行都没问题，cleanbuild会报错，If this is an unrelated build, it must have its own settings file. 但是可以正常编译完成。

这个是路径问题，解决方案，查看 issue #2

from composingbuilds-vs-buildsrc.

@hi-dhl
AS:Android Studio Arctic Fox | 2020.3.1 Canary 12
Gradle:3.5.4
我刚试了下，发现貌似可以在Project目录内放VersionPlugin了。

from composingbuilds-vs-buildsrc.

@hi-dhl
AS:Android Studio Arctic Fox | 2020.3.1 Canary 12
Gradle:3.5.4
我刚试了下，发现貌似可以在Project目录内放VersionPlugin了。

嗯嗯，是可以放，能帮忙看一下 新版本 是否会出现如下警告日志

If this is an unrelated build, it must have its own settings file

from composingbuilds-vs-buildsrc.

@hi-dhl
AS:Android Studio Arctic Fox | 2020.3.1 Canary 12
Gradle:3.5.4
我刚试了下，发现貌似可以在Project目录内放VersionPlugin了。

嗯嗯，是可以放，能帮忙看一下 新版本 是否会出现如下警告日志

If this is an unrelated build, it must have its own settings file

没有，挺正常的。你可以试下，不过我项目特殊，有地方对gradle特殊操作了报错。你可以对你Sample试下，就把VersionPlugin放到根目录，Setting再该下VersionPlugin的路径就行了、；

from composingbuilds-vs-buildsrc.

@hi-dhl
AS:Android Studio Arctic Fox | 2020.3.1 Canary 12
Gradle:3.5.4
我刚试了下，发现貌似可以在Project目录内放VersionPlugin了。

嗯嗯，是可以放，能帮忙看一下 新版本 是否会出现如下警告日志

If this is an unrelated build, it must have its own settings file

没有，挺正常的。你可以试下，不过我项目特殊，有地方对gradle特殊操作了报错。你可以对你Sample试下，就把VersionPlugin放到根目录，Setting再该下VersionPlugin的路径就行了、；

可能新版本 Google 修复了吧，我下载新版本试试

from composingbuilds-vs-buildsrc.

添加新的依赖，都需要重启AS吗？

from composingbuilds-vs-buildsrc.

添加新的依赖，都需要重启AS吗？

不需要

from composingbuilds-vs-buildsrc.

composingBuilds怎么检测依赖更新呢

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

我也觉得不应该有太大构建时间差距，主要项目比较复杂了，变量因素太多。但是如果不用真的生产项目去试，单纯用demo，又不好验证可行性。

from composingbuilds-vs-buildsrc.

我怎么用这个会出现kotlin 的依赖重复的现象，有1.3.72. 有1.5.10的 jdk7 jdk8的，但是我把该改的都改了，项目中没有1.3.72

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

我也觉得不应该有太大构建时间差距，主要项目比较复杂了，变量因素太多。但是如果不用真的生产项目去试，单纯用demo，又不好验证可行性。

可以从多方面考虑，依赖只是其中一个因素， 用 demo 只是验证其中一个因素，是否可以达到预期的想过， 也要结合实际项目的情况，例如从多 Project 、多modul 的管理的角度，可以来带来的收益最大化，毕竟每次的改造花费的时间成本也很大

from composingbuilds-vs-buildsrc.

我怎么用这个会出现kotlin 的依赖重复的现象，有1.3.72. 有1.5.10的 jdk7 jdk8的，但是我把该改的都改了，项目中没有1.3.72

我之前好像也出现过，忘记怎么弄的了，贴出一下你的配置，看一下项目使用的 kotlin 的版本。

from composingbuilds-vs-buildsrc.

我怎么用这个会出现kotlin 的依赖重复的现象，有1.3.72. 有1.5.10的 jdk7 jdk8的，但是我把该改的都改了，项目中没有1.3.72

我之前好像也出现过，忘记怎么弄的了，贴出一下你的配置，看一下项目使用的 kotlin 的版本。
versionplugin 配置

不过我找到了一个相似的 文章 https://www.wantedly.com/companies/wantedly/post_articles/302749

from composingbuilds-vs-buildsrc.

from composingbuilds-vs-buildsrc.

引入Composing Build后项目sync, build时间都变慢了。跟之前用ext方式管理，能明显感觉出来慢很多。
@Weightang 你说的kotlin-stdlib:1.3.72我的项目也有这个依赖。分析了整个项目，发现如下引用。像是AndroidStudio 编译器引用的1.3.72版本

from composingbuilds-vs-buildsrc.

引入Composing Build后项目sync, build时间都变慢了。跟之前用ext方式管理，能明显感觉出来慢很多。
@Weightang 你说的kotlin-stdlib:1.3.72我的项目也有这个依赖。分析了整个项目，发现如下引用。像是AndroidStudio 编译器引用的1.3.72版本

你是用那个kotlin 版本的？ 也看下你的配置

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

我也觉得不应该有太大构建时间差距，主要项目比较复杂了，变量因素太多。但是如果不用真的生产项目去试，单纯用demo，又不好验证可行性。

最近又新开了个项目，采用了复合构建的方式去实践，可以确定，构建速度明显变慢，同时修改依赖重新同步的速度也很慢。

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

我也觉得不应该有太大构建时间差距，主要项目比较复杂了，变量因素太多。但是如果不用真的生产项目去试，单纯用demo，又不好验证可行性。

最近又新开了个项目，采用了复合构建的方式去实践，可以确定，构建速度明显变慢，同时修改依赖重新同步的速度也很慢。

分享我的使用经验，
在关注到这个同步sync时间变长变慢的很致命的缺点的时候，我试着在我的项目里面反复编译发现，确实编译出现变慢，每次编译都会在某一任务产生大量耗时，我此时的心情是绝望的，本意是想要快速构建依赖，但是确出现这种问题，让我一度产生放弃的想法，但是直到第二天我重新打开项目又发生了好转，每次编译都很快，进过对比我发现了些许问题。
首先看正常快速的编译的情况下是什么样子的

在不正常编译过程中，如下图

仔细看图这里的Task :VersionPlugin:jar，并没有执行UP_TO_DATE 操作，而是选择重新编译，一般当我们升级了VersionPlugin中的依赖的时候，就会 重新编译VersionPlugin:jar插件，不执行UP_TO_DATE 操作，然后当下次编译又会复用之前编译的VersionPlugin:jar，复用则会提示UP_TO_DATE 操作，此时回想昨天莫名其妙总是每次编译都重新编译非常长的时间，一度达到8分钟之久的情况，我记忆中每次都是重新编译VersionPlugin:jar插件，从来不复用VersionPlugin:jar插件。然后在重新编译VersionPlugin:jar插件的过程中耗费大量时间【根据观察，大量时间耗费在，我们定义的allprojects->repositories 中配置的多个maven地址的寻址和download的过程中】。我折腾了一天都是卡，慢，难用，只能在maven地址的寻址过程中中想办法，最后统一换成了阿里云仓库地址，照样慢，直到下班都没搞定，离奇的是第二天，我的项目编译重新变得又快又稳，编译VersionPlugin:jar插件后每次编译都是产生了复用，

到现在发帖为止，我的同一个项目经历了从昨天每次编译都又卡又慢的情况变成了今天的又快又稳，原因我没找到，两天不同的地方就是昨天我复制了好多个老项目，并升级为ComposingBuilds模式，来回各种折腾，又一天没有重启电脑，是不是这个原因导致的电脑混乱进而导致编译又慢又卡就不得而知了，上面的情况也是给各位提供一点使用经验

from composingbuilds-vs-buildsrc.

使用了复合构建，依赖暂时不去修改，试了很多次，整体rebuild project时间变慢了。不知道原因为何。
还有顺便提供一个操作，在非build.gradle的的脚本中（项目有大量的module，可能抽取了某些通用的xxx.gradle）是无法访问到该插件内容的，可以把类添加到project的extensions，这样也可以避免在脚本中导包，这样都可以愉快的访问：

class DependencyRepoPlugin : Plugin<Project> {

    override fun apply(target: Project) {
        println("[${DependencyRepoPlugin::class.java.simpleName}] apply.[${target.name}]")
        // 在非build.gradle的的脚本中无法访问到该内容，添加到extensions
        target.extensions.add("DependencyRepo", DependencyRepo)
    }

}

rebuild project 的时间，影响的因素很多，如果除掉模块之间的依赖等等，但从lib去看，再次 rebuild 时间应该会很快

我也觉得不应该有太大构建时间差距，主要项目比较复杂了，变量因素太多。但是如果不用真的生产项目去试，单纯用demo，又不好验证可行性。

最近又新开了个项目，采用了复合构建的方式去实践，可以确定，构建速度明显变慢，同时修改依赖重新同步的速度也很慢。

分享我的使用经验，
在关注到这个同步sync时间变长变慢的很致命的缺点的时候，我试着在我的项目里面反复编译发现，确实编译出现变慢，每次编译都会在某一任务产生大量耗时，我此时的心情是绝望的，本意是想要快速构建依赖，但是确出现这种问题，让我一度产生放弃的想法，但是直到第二天我重新打开项目又发生了好转，每次编译都很快，进过对比我发现了些许问题。
首先看正常快速的编译的情况下是什么样子的

在不正常编译过程中，如下图

仔细看图这里的Task :VersionPlugin:jar，并没有执行UP_TO_DATE 操作，而是选择重新编译，一般当我们升级了VersionPlugin中的依赖的时候，就会 重新编译VersionPlugin:jar插件，不执行UP_TO_DATE 操作，然后当下次编译又会复用之前编译的VersionPlugin:jar，复用则会提示UP_TO_DATE 操作，此时回想昨天莫名其妙总是每次编译都重新编译非常长的时间，一度达到8分钟之久的情况，我记忆中每次都是重新编译VersionPlugin:jar插件，从来不复用VersionPlugin:jar插件。然后在重新编译VersionPlugin:jar插件的过程中耗费大量时间【根据观察，大量时间耗费在，我们定义的allprojects->repositories 中配置的多个maven地址的寻址和download的过程中】。我折腾了一天都是卡，慢，难用，只能在maven地址的寻址过程中中想办法，最后统一换成了阿里云仓库地址，照样慢，直到下班都没搞定，离奇的是第二天，我的项目编译重新变得又快又稳，编译VersionPlugin:jar插件后每次编译都是产生了复用，

到现在发帖为止，我的同一个项目经历了从昨天每次编译都又卡又慢的情况变成了今天的又快又稳，原因我没找到，两天不同的地方就是昨天我复制了好多个老项目，并升级为ComposingBuilds模式，来回各种折腾，又一天没有重启电脑，是不是这个原因导致的电脑混乱进而导致编译又慢又卡就不得而知了，上面的情况也是给各位提供一点使用经验

感谢分享

from composingbuilds-vs-buildsrc.

还是用换回用buildSrc 吧，你们解决了它会导入你有的ktolin 版本架包

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle

如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle

如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

应该没办法的

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle

如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

你看，最外面的 build.gradle 都无法使用 versionplugin中的数据，更何况common.gradle，versionplugin是个插件， build.gradle 中是执行插件应用的

应用了后在子项目中才可以 使用 VersionPlugin 中的类，想要在还最外层的build.gradle使用，就是和引入VersionPlugin插件是同一个时刻，应该是不可以，有人有更好的方法可以使用的话，请留言。我学习下

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle
如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

应该没办法的

有解决办法的，可以看 #4 (comment)

from composingbuilds-vs-buildsrc.

谢谢楼上几位大兄弟。上面问题解决了。
解决方法：

1. 

2. 在你的xxbuild.gradle里直接引用 VersionConfig
   android {
   ..
   compileSdk VersionConfig.compileVersion
   }
   新的问题：
   但是如果想把" 1.5.30 "放到 VersionConfig 里进行管理就不行了，因为插件的加载是在buildscript之后的。如果你的项目是组件化形式，并且抽取了通用的gradle配置，那么用 Composing builds 管理依赖配置 得三思哈。
   buildscript {
   ..
   dependencies {
   classpath "com.android.tools.build:gradle:7.0.1"
   classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.30"
   }
   }

plugins {
// 这个 id 就是在 versionPlugin 文件夹下 build.gradle 文件内定义的id
id "com.hi.dhl.plugin" apply false
}
subprojects { subproject ->
// 默认应用所有子项目中
apply plugin: 'com.hi.dhl.plugin'
}
如果是用buildSrc进行管理依赖配置，因为buildSrc是在gradle的初始化之前加载的，所以在项目中的任意位置都可以引用，这么想，还是挺方便的。

from composingbuilds-vs-buildsrc.

My Application
|--app
build.gradle
common.gradle
如果我想在 common.gradle里使用VersionPlugin里的依赖，直接报错。
Caused by: groovy.lang.MissingPropertyException: Could not get unknown property 'BuildConfig' for extension 'android' of type com.android.build.gradle.internal.dsl.BaseAppModuleExtension.
请问有啥解决办法吗？

应该没办法的

有解决办法的，可以看 #4 (comment)
新的问题：
但是如果想把" 1.5.30 "放到 VersionConfig 里进行管理就不行了，因为插件的加载是在buildscript之后的。如果你的项目是组件化形式，并且抽取了通用的gradle配置，那么用 Composing builds 管理依赖配置 得三思哈。
buildscript {
..
dependencies {
classpath "com.android.tools.build:gradle:7.0.1"
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.30"
}
}
这个可以解决吗？我就对这个问题无可奈何呀

from composingbuilds-vs-buildsrc.

composingBuilds怎么检测依赖更新呢
使用这个插件，很棒
Check for Dependency Updates

from composingbuilds-vs-buildsrc.

gradle 7.2（Android Studio Chipmunk） 依然无法跳转

from composingbuilds-vs-buildsrc.

gradle 7.2（Android Studio Chipmunk） 依然无法跳转

@Joslyn-Chen 可以看一下这个的方案 #11 (comment)

from composingbuilds-vs-buildsrc.

gradle 7.3.3 (Android Studio Chipmunk) 并不支持双向跳转，VersionPlugin放在project目录下使用includeBuild("./VersionPlugin")执行Clean Project还是会出现If this is an unrelated build, it must have its own settings file.

from composingbuilds-vs-buildsrc.