Rethink and rebuild from the ground up
Hi! I learned about Gradm by coming across your issue comment in the Gradle repo. In it, you said:
Although I'm still using Gradm myself, I wouldn't recommend it to others—I believe it needs to be completely rethought and rebuilt from the ground up.
I'm curious to know what needs to be different (besides multiple updates and resolving open issues), and how soon the successor will see the light of day? I'm fascinated by this project, and would absolutely give it a try if the issues were addressed. Is that what version 4.0 (currently in beta) is for?
Thank you very much for your interest in Gradm.
First of all, I want to clarify that Gradm 4.0 is the original intention that prompted me to rethink, not the final product. Therefore, after a complete rework, Gradm will skip the stable version of 4.0 and proceed to Gradm 5.0.
I have many expectations for Gradm. I'll outline them below.
Compatibility
- I hope Gradm is compatible with the Gradle Version Catalogs format, so users can get started with Gradm without learning new syntax.
- This would allow free switching between Gradm and Gradle Version Catalogs.
- I believe this is a capability that good infrastructure should provide.
Background (Outdated legacy)
- As for why I once insisted on designing a custom format, it mainly had to do with the historical context at the time.
- Back then, Gradle Version Catalogs were still in preview and lacked IntelliJ IDEA plugin support.
- I also couldn’t find a suitable way to obtain the dependency information I expected from Maven repositories.
- I also wanted to consolidate the configurations in
org.gradle.api.artifacts.repositories.InclusiveRepositoryContentDescriptorinto my own configuration file. - Later, I gradually found solutions or trade-offs for the above issues, which led to the ideas I mentioned in the original issue.
Extensibility
- I hope Gradm can obtain dependency versions from outside Maven repositories, such as GitHub Releases.
- When searching for the latest versions, I hope to exclude unwanted versions via extension plugins or configuration proactively.
Lightweight
- I want Gradm to remain healthy overall and easy to maintain.
Standalone
- I hope Gradm can run independently outside the Gradle ecosystem.
CI/CD Friendly
- I hope Gradm can integrate deeply with CI/CD tools so that pipelines can automatically obtain dependency versions. There are certainly more expectations, but the above is enough to explain why I decided to rebuild Gradm completely.
A quick note on the release timeline for Gradm 5. Unfortunately, I currently have a full-time job with numerous tasks to complete, which is quite exhausting. For my well-being, I can only devote a small portion of my spare time to coding. I also have many personal projects (over 20 active), so the time I can allocate to Gradm is minimal.
But I very much hope Gradm 5 will be released someday, rather than remaining only in my plans and local demos. I sincerely invite you to check out my picsum and gradle-project-initializer-template projects and try Gradm 4.0.0-beta03 to experience Gradm firsthand.
I’m very much looking forward to your feedback!