what's the kotlin equivalent to ```buildConfigField("String", "API_KEY", API_KEY)``` and under where...

# gradle

[Kaj Koivunen]

what's the kotlin equivalent to

buildConfigField("String", "API_KEY", API_KEY)

and under where should it be placed in the default build script intellij IDEA gives you for a jvm console project? I tried just about anything and it just seems buildConfigField is not recognized on kotlin side of things

[Sam]

buildConfigField is part of Android, it won’t exist in a basic JVM console app

[Vampire]

buildConfigField afair is something specific to Android projects, added by the Android Gradle Plugin.

[Vampire]

So in a "jvm console project" this will not be available

[Kaj Koivunen]

in that case what would be the ideal way to store an API key in gradle.properties to net get it commited or should I do something else entirely?

[mbonnin]

If you're building an Android, Web or iOS, client, commit your API key, it's not secret anyway

[Kaj Koivunen]

if you read above, I'm not

[mbonnin]

Right sorry

[mbonnin]

Even for a console project, if you distribute it, you distribute your secret

[mbonnin]

If you really don't want to commit it, you can create a Gradle task that generates a Kotlin file and add it to your sources

[Vampire]

Doesn't mean it should be in the source repository 😄

[mbonnin]

I'm more and more convinced it should

[mbonnin]

https://blog.mbonnin.net/about-the-android-makers-app-security-and-google-servicesjson

[Vampire]

But yeah, the question is what you want to do exactly.
There are for example online services where you can store your secrets and your application just requests it from there at runtime.
If you want to include it in the final application, I usually have a properties file with a placeholder and then use expand in processResources task configuration to fill the placeholder with the actual value. The code can then read it from that properties file.

[Kaj Koivunen]

in the finished app the api key would be something the user provides themselves through a dialog but in the meantime I was just looking for a way to hold it somewhere not commited but easily usable

[Kaj Koivunen]

I suppose I'm just going to have to get the dialog and input working first if there's no easy way to just have a build variable

[Vampire]

You could e. g. set it as environment variable or system property or commandline argument for the run task and then use the run task to test your app and read it from where you configured it

[Vampire]

if there's no easy way to just have a build variable

The way I described is pretty easy

[Adam S]

what about putting the property in a file, ./src/main/resources/local.properties, and then adding the file to .gitignore? In code you can try and load the file, and if it’s not present, then prompt the user for input?

[Vampire]

Also a possibility, yeah

[Vampire]

Many ways lead to rome 😄

[Adam S]

for a more complete way of handling properties with defaults and fallbacks and environment variables, take a look at https://github.com/sksamuel/hoplite

[kevin.cianfarini]

If this is for a CLI project then you should probably be using environment variables

[gildor]

Yep, environment variable or system config