Hello. Not sure how much of a "not koltin" my ques...

# gradle

[Vlad]

Hello.
Not sure how much of a "not koltin" my question is, but I am really struggle to implement such simple thing as:

plugins {
    ...
    val witSomePlugin: Boolean by settings

    if (witSomePlugin) {
        alias(libs.plugins.somePlugin)
    }
}

I just need to conditionally add a plugin into one specific subproject depends on the value in settings/properties.
Main issue that I need to add to specific subproject only (android application project) and I can't add it in deeper subproject which would be added to the androidApp project.

I see in some posts that val witSomePlugin: Boolean by settings now can be used inside subproject's plugins{} block, but it doesn't work for me.
It is very important to not add that when not needed, because it rewrites complied classes.

[Vampire]

I don't think you can do that, especially not by settings in a project build script.
In a settings script maybe, but even then : Boolean will not work as form the properties file you get a String, not a Boolean.

You could for example write a convention plugin to conditionally apply the plugin and apply that convention plugin.
Or you could use the legacy way to apply a plugin using apply(...) inside the if outside the plugins block.
But either way it is not the best idea.
You can then also not use type-safe accessors to configure that plugin as they would not always be present.

[Vlad]

Insane that I stuck so badly for such a simple thing.
I wonder if

But either way it is not the best idea.

Then what would be the best/acceptable idea?

And is the problem just by accessing that conditional data from the properties?
If we just replace by settings with system env System.getenv("withSomePlugin") we will be good to go, just losing the comfort of having it in the properties

[Vampire]

"not the best idea" was referring generally to applying plugins conditionally like that, especially in Kotlin DSL and if you need to further configure it.

[tapchicoma]

what about:

plugins {
   id "plugin" apply false
}
if (withSomeCondition) plugins.apply("plugin-id")

?

[tapchicoma]

actually was already proposed 😅

[Vlad]

Aha.
Well I have multi-flavored/branded mobile object and that plugin really needed only for one of the flavors and in the androidApp module unfortunately. If I put it in more deeper dependency it doesn't work properly.

As of the legacy way - it indeed worked, I can do everything I wanted just outside of the plugins {} block: both properties and if () apply available there.

I was reading using plugin docs so many times always skipping "Legacy Plugin Application" block 🤦‍♂️
Thank you for the help and your time.
Gradle is so complicated. Although I build with both android and iOS apps knowing only kotlin so I won't complain too much 🙂

[Vampire]

what about

Yep, that was what I meant with legacy application in the condition.
But nevertheless not really good practice in most cases. 🙂

Gradle is so complicated.

Not really unless you need to do strange and unusual things. 🙂
For those it can become a bit complicated yes, but that's the price for having the great flexibility and freedom you have, to do whatever you want and need to.

[Vlad]

Dunno if my project considered unusual. It is for my experience.
I am dealing with KMP project for android + ios with flavors/brands and for the post I need to enable Microsoft Intune to some of the flavors.
And I want to work with that SDK only in kotlin.

I could drop that "not recommended way" if it would be possible in my androidApplicationModule to look for another gradle project (:intune) which can have the plugin applied without any conditions, and ask that project to apply the plugin for me(if the project is added to the build, because it is conditional dependency). If that makes sense.
Honestly the whole problem is unperfection of that particular plugin that it can't do its job if added in subproject. Maybe they (MS) had their own issues with not really complicated gradle 🙂

[Vampire]

Well, writing plugins can become complicated quite easily, yes, because if you write a plugin you by definition have non-normal requirements.
If you write a plugin for others, then for these others it should then again be non-complicated again if the plugin is written properly. 🙂
So complain to that plugin author / maintainer to fix their plugin. 😄

ask that project to apply the plugin for me(

If you meant that the other project should cross-configure your project, that would be even worse and is never the right thing to do. Any cross-project configuration or even only getting information of the model of another project is a veeery bad idea and highly discouraged.

[Vlad]

Any cross-project configuration or even only getting information of the model of another project is a veeery bad idea and highly discouraged.

Yea, I thought so and didn't try that path.
But I am kinda forced anyway. I need the library plugin in one project but the library itself in another subproject and the logic of conditionally connecting that another project in shared project 😄

[CLOVIS]

But I am kinda forced anyway. I need the library plugin in one project but the library itself in another subproject and the logic of conditionally connecting that another project in shared project 😄

I don't know exactly what you're doing here, but there is definitely another way of doing this. This is just a direction with a whole lot of hurting.