Question: why dependencies.gradle?

[dmfrey]

Now that you've refactored this into a single project (no longer a multi-project build) why keep dependency declarations in dependencies.gradle.

Moving them into the app/build.gradle would allow their references to integrate better with Android Studio as well as provide notifications when key dependency versions are updated. In its current form, those notifications are lost as the IDE doesn't follow up the gradle graph of build files.

[kijka]

Agree, dependencies.gradle only useful if our features is separate Gradle modules

By the way Android Studio sometimes don't provide notification when there is new version of library available and better to manually check: Analyze -> Run inspection by Name -> Newer library versions available

Example of simple app/build.gradle: https://github.com/vladsonkin/bikeindex/blob/master/app/build.gradle

[tentenponce]

I guess scalability is much more important than being notified if your library is outdated. Atleast keeping dependencies on a project-level will make the the project ready incase you want to divide each modules/layers.

[St4B]

In each approach there are advantages and disadvantages. By keeping them in build.gradle file it is easier to check if there is a newer version. By keeping them in dependencies.gradle it is easier to scale. Also we have smaller gradle files which contain code that matters (namely tasks).

Personally, I prefer to have the dependencies defined in a external file and use this plugin https://github.com/ben-manes/gradle-versions-plugin in order to check for updates. By defining a gradle task (and not use Analyze -> Run inspection by Name -> Newer library versions available as mentioned by @vladsonkin) we can add checks in our CI process.

I have created a pr with this approach (https://github.com/android10/Android-CleanArchitecture-Kotlin/pull/75). You only have to run ./gradlew dependencyUpdates