Solutions like Dependabot or Renovate update but don't merge dependencies. You need to do it manually while it could be fully automated! Add a Merge Queue to your workflow and stop caring about PR management & merging. Try Mergify for free. Learn more →
Idiomatic-gradle Alternatives
Similar projects and alternatives to idiomatic-gradle based on common topics and language
-
nowinandroid
A fully functional Android app built entirely with Kotlin and Jetpack Compose
-
slack-gradle-plugin
Gradle and IntelliJ build tooling used in Slack's Android repo
-
Appwrite
Appwrite - The open-source backend cloud platform. The open-source backend cloud platform for developing Web, Mobile, and Flutter applications. You can set up your backend faster with real-time APIs for authentication, databases, file storage, cloud functions, and much more!
-
-
Gradle buildSrcVersions
Life is too short to google for dependencies and versions
-
gradle-maven-publish-plugin
A Gradle plugin that publishes your Android and Kotlin libraries, including sources and javadoc, to Maven Central or any other Nexus instance.
-
custom-floating-action-button
This view is for replacement of standard Floating Action Button from Google Support Library. It is easy to use, customizable and you can also add text to button
idiomatic-gradle reviews and mentions
-
Android Developers Blog: Kotlin DSL is Now the Default for New Gradle Builds
You should look into how https://github.com/jjohannes/idiomatic-gradle and similar projects handle it (nowinandroid has a good set up as well).
-
just enough gradle
And finally, look at the idiomatic gradle repo. There is also a free video series that goes with this Understanding Gradle – Video Series. There are lots of bad practices in gradle that will slow your builds down, like using allProjects {}
-
For builds: Gradle vs Maven vs IntelliJ
For a long-lived (aka - something you'll maintain and may grow) multi-module project, I'd suggest following the idiomatic gradle structure. But there's a lot to unpack there, so it may not be the ideal thing to start with. Once you grok it though, that structure scales incredibly well, and allows you to avoid duplicating lots of configuration (via 'precompiled script plugins', largely in the build-logic project in that repo), and make use of build caching without having to modify things.
I'd suggest getting rid of buildSrc, and just using build composition. I mentioned in another response, but check out https://github.com/jjohannes/idiomatic-gradle for how to use precompiled script plugins that are connected to the project via includedBuilds. The only issues I've had with this are generally resolved by just running the sub-build independently to resolve any caching issues in the 'primary' build. A simple gradlew build --settings-file ./build-logic/settings.gradle.kts run will generally resolve that, and that issue seems largely because of the 'root' build being a peer or anscestor of the included build (due to legacy structure of the project, an issue the linked example repo does not have).
-
A note from our sponsor - Mergify
blog.mergify.com | 27 Sep 2023
Stats
jjohannes/idiomatic-gradle is an open source project licensed under Apache License 2.0 which is an OSI approved license.
The primary programming language of idiomatic-gradle is Kotlin.