This message was deleted.
# community-support
s
This message was deleted.
c
iirc
pluginManagement
is processed separately, it doesn’t see the rest of the script.
☝️ 1
a
do you know of any way to do something like this? it seems you can't declare enums inside that scope either
I could just drop the enum and use strings but that's less nice
v
Is this super-over-simplified? Or why would you want to declare an enum to use it once?
a
it's being used to determine repository sources via environment variables and how it should handle connections based on that
v
But I still don't get it. If you could define it inside
pluginManagement { ... }
it would only be usable in there, so why not right away doing the logic in there directly? What do you need the enum for?
a
this works, but this is only in the repositories block, there are plugins in the same repos, which can't be resolved in this way unless you drop the reuse of the enum and make everything strings
v
Actually, what you showed is not valid code. There is no top-level
repositories { ... }
block in a settings script.
But assuming you meant
dependencyResolutionManagement { repositories { ... } }
, yeah, well, that's probably your only solution. As was said, the
pluginManagement { ... }
block is special and needs to be self-contained, and the Kotlin language does not allow you to have an
enum
in there. But at least you can avoid repeating by also configuring the dRM repos inside the pM block like:
Copy code
// the plugin management block is evaluated first separately, do not change this to
// listOf(pluginManagement.repositories, dependencyResolutionManagement.repositories)
// instead that would change the semantics
pluginManagement {
    listOf(repositories, dependencyResolutionManagement.repositories).forEach { repositories ->
        repositories.apply {
            // configuration here
        }
    }
}
c
you know, I understand that certain things need to happen specially inside certain blocks, but how is an enum not fully defined at that point? what in the ... is this even really kotlin/groovy? Like ...how?
c
pluginManagement
and
plugins
are special, due to lifecycle requirements - they need to be processed separately to determine the classpath, such that the rest of the script can be compiled. https://docs.gradle.org/8.0.2/userguide/plugins.html#sec:constrained_syntax
c
but... how does that work? it's terrifying that those aren't processed by "language" that means that gradle is doing some kind of pre-processing that extracts and evals
c
by definition it is necessary to do preprocessing due to the lifecycle requirements - the Kotlin compiler needs a classpath to compile code, that classpath is defined (in part) by the plugins in the script.