```ext { environmentConfig = [ prod: [...
# community-support
v
Copy code
ext {
    environmentConfig = [
        prod: [
            foo-app : [
                webUrl           : "...",
                linkUrl          : "...",
                marketingLinkUrl : "...",
            ],
            ...
        ],
        preprod: [
            ...
        ],
        ...
}
have a config.gradle where I keep a neat dictionary config of bunch of urls per environment per app why does this break `isolated project`s? also, is there a more idiomatic way? maybe it should be a
.properties
file?
v
Besides that any time you use
ext
/
extra
properties you should feel dirty, according to a former Gradle developer, what do you mean with break, what happens? If you have that block for example applied on the root project and when they to access that extra property from a subproject, that is the violation. Better have a convention plugin that registers an extension that provides the values. Then you also have proper types of you need anything else than string, and also is you would use Kotlin DSL (highly recommended), you would have proper IntelliSense for it.
v
Dont you feel putting build time constant into convention plugin is too "far away" from the build? Is really some. properties or yaml file not idiomatic?
v
You can define them in a file, sure. But still you somewhere need to parse that file and provide the parsed values. So that will then be in the convention plugin. 🤷‍♂️
v
so providing a path to the convention plugin and get some sort of data class processor back?
v
Just parse the file in the convention plugin and register an extension with the result so that the build logic can access it?
v
I see, but in that case. why is it important to have it in a convention plugin? to not duplicate it per app, since even static root function is banned?
v
I don't know what you mean with "static root function". If you want something in multiple projects, have a convention plugin. Or actually in this case you could also make a shared build service so that the file is then only parsed once and all projects can use the values if it should be the same values for all. Usually the best in such a situation is to have a shared build service to only parse the file once, and a convention plugin that registers an extension that makes the values accessible conveniently, fed from the share build service parse result.
💯 1