So i'm trying to setup a project from scratch, and...
# declarative-gradle
m
So i'm trying to setup a project from scratch, and i'm running into an issue declaring dependencies, and i have a few questions: • How does the android-ecosystem plugin decide which version of compose to use? • How do i get support for version catalogs? Whenever i try to use the version catalog, i'm getting an error that says "libs" is not defined. I can put the dependency inline, but AS preview wants me to move to the version catalog (rightfully so) and then i get that error on syncing.
I can see the now in android project they don't use "libs" in .dcl files either. I suspect maybe this is due to it expecting the conventions to declare shared dependencies like this? In our case, we have a large multi module project where we'd want the version catalog, and we'd want to selectively include certain dependencies and don't want to create a unique software type for each.
j
How does the android-ecosystem plugin decide which version of compose to use?
You don't need to do that anymore, apply the Kotlin Compose compiler plugin with the same version Kotlin uses.
m
@Javi That's the compose compiler, not the compose runtime itself.
The compose compiler isn't opinionated about what runtime version of compose you are using. In the non declarative world, i still have to add all of my implementation dependencies, and import the correct bom for the version of compose i want to run with.
a
FYI: currently
.dcl
files don't support version catalog. As far as I know there are plans to support sharing dependency versions, but there are still some higher priority topics that get more attention atm
m
Thanks @Anze Sodja. I like the generl approach so far. I think definitely that there's some features that, if not implemented, could be big barriers to adoption. Version catalogs is one of them. Another one would be the idea of "mixins". ie, being able to say extend the
androidLibrary
software type so that you could do things like add in kotlinx serialization or kover. Things that are not a "core" part of an android project, but rather cross cutting concerns that could be applied to various types of software.
p
Version catalog support will definitely come, eventually
We are currently designing/prototyping composability/extensibility, it's a must
As for the compose version, you can't specify the version declaratively in our prototype, yet
You could open an issue on https://github.com/gradle/declarative-gradle/issues about it
m
j
@Paul Merlin is there an ETA about when we will be able to create our own plugins?
p
You can already. It's not documented, requires internal unstable APIs, and, at this stage there.s absolutely a guarantee that we will break stuff, repeatedly. IOW, you can for learning/evaluation purpose but none of this is production ready.
We would be happy to get feedback about writing plugins. It's something we want to make easier for you going forward.
j
I would like to create the declarative one for hubdle, can you share some links to use as guidelines? I think the only limitation I had is I need to apply multiple plugins, not sure if that limitation has been removed. Hubdle is already declarative so the code should look more or less the same within dcl files
p
The only thing we currently have is the source of the prototype plugins at https://github.com/gradle/declarative-gradle/tree/main/unified-prototype
šŸ‘ 1
Your plugin that registers the software type can apply multiple plugins already.
thank you 1
šŸ‘€ 1
Given my disclaimer above, don't publish this in the same artifact as a production plugin. All this might break on the next Gradle nightly
j
Do you mean any try should be published only locally?
m
I think the point @Javi is that the APIs could break with any gradle or agp update at this point, so if you create a custom software type and publish it somewhere public, it should be it's own thing and not bundled with some other stable plugin
šŸ‘ 2