This message was deleted Gradle Community #community-support

Join Slack

This message was deleted.

# community-support

Slackbot

08/20/2022, 1:05 PM

This message was deleted.

Vampire

08/20/2022, 1:24 PM

What you get from

val libs = extensions.getByType<VersionCatalogsExtension>().named("libs")

is the full version catalog. You get both, the libs and the plugins from it, but both only stringy. Type-safe accessors you only get using a hack I detailed at https://github.com/gradle/gradle/issues/15383

👀 1

Stylianos Gakis

08/20/2022, 1:52 PM

This does seem to kinda work, only gotta figure one more thing to try this out. The way we apply these in a normal build.gradle.kts is with this syntax

alias(libs.plugins.xx)

but this

alias

function doesn’t seem to be available in my convention plugin configuration. Is there something I can do there too, like some way to use the

libs.plugins

in a

apply()

instead?

Stylianos Gakis

08/20/2022, 2:00 PM

I guess I can potentially do

apply(libs.plugins.xx.get().pluginId)

but then rely on the version of it being applied on the root build.gradle with

apply = false

but that doesn’t sound that great either 🤔

Vampire

08/20/2022, 2:16 PM

Hard to say wihtout more information. For example if you use precompiled script plugins for the convention plugin, it should be the same. If not, then you probably have to do it like shown. But you don't depend on the plugin bein added to the root build script, but through having the plugin as dependency of the convention plugin it is already in the classpath.

Stylianos Gakis

08/20/2022, 2:21 PM

Getting a bit of gradle keyword overload here tbh 😅 Kinda hard to follow what you mean, but I’ll simply play around with it and see where it goes. Thank you a lot for the help!

Stylianos Gakis

08/20/2022, 2:30 PM

Looking at the docs of the

inline fun <reified T : Any> Project.the(): T

function, I read

Copy code

/**
 * Returns the plugin convention or extension of the specified type.
 *
 * Note, that the concept of conventions is deprecated and scheduled for
 * removal in Gradle 8.
 */

Since this is to be removed, is there something coming in to replace it? Seeing it made me double think if I even want to go that approach if I must revert it in gradle 8 anyway.

Vampire

08/20/2022, 2:32 PM

Only conventions are deprecated, not extensions. And what is called "convention" there has nothing to do with "convention plugins", that's not related actually. Just unlucky wording.

Stylianos Gakis

08/20/2022, 2:34 PM

Damn there’s a lot of keywords one needs to be familiar with to have discussions about gradle, it’s quite a challenge for someone newer to it. Thanks for taking the time to clarify this to me too though, I really appreciate it!

Vampire

08/20/2022, 4:33 PM

Yeah, don't worry. That's the same with most universes. :-) Comes time, comes knowledge of terms.

gradlephant 1

Stylianos Gakis

08/20/2022, 11:01 PM

Yeah, got this diff actually, it all seems to work! For some context, I went into this rabbit hole trying to apply the tips provided on the android-cache-fix-gradle readme to not use subProjects but use my convention plugins to apply this plugin 😅 I hate referring to things with their string, I think I’ll keep this way, and hopefully there will be a more standard way to do this soon without this as you called it “small work-around”.

👌 1

3 Views

Open in Slack

Previous Next