def props = ...read profs from file
appAutomateUpload {
    username = props["username"]
    password = props["password"]
}

I have a plugin which needs credentails. I have those in a file. How would I best set this up so the properties are not read every build? Is this a bad design on plugin part? Should it be working expecting a file path and read the file lazily when actually running the task? Or can I lazy configure a extension?

The overhead of reading/parsing a (presumably small) file is likely insignificant and may not be worth optimizing for. If you do wish to avoid reading this on every build, the best bet is to use Gradle’s configuration cache.

I mean it went from this

loop all android variants
	...
	tasks.register("appAutomateUpload$variant") {
		def props = .... read prefs from file
		username = props["username"]
		password = props["password"]
	}

(as you can see props are read lazily) with task body being in buildSrc, to creating a plugin which will be moved out to a separate repo now it feels like a downgrade

agreed re: cc - it’s great when it works, but…

I noticed deploy plugins take in files mostly, or have this dual api

play {
    serviceAccountCredentials.set(file("your-key.json"))
}

that will be done at configuration time, which usually isn’t desirable. You’ll also need to check that the file isn’t read/parsed more than once (for optimal performance).

yea so I can only pass the file handle — but then the layout of the properties file needs to be documented since its hardcoded internally in the plugin now

your plugin can provide a Provider<Map<String,String>> that handles reading the file, parsing it into a map (lazily - only when resolved, and only once).

but what would it return, the map? then the expected map keys need to be documented

it return a provider to a map, yes. When resolved it’s used as in your examples

props["username"]

. Yea, type safety and groovy ugh…

appAutomateUpload {
    credentials {
    	def props = ...read profs from file
    	Credentials(props["username"], props["password"])
    }
}

something like this?

be sure not to resolve the provider until in the execution phase - inside the tasks that need the props, generally.

whats a provider in gradle speak, just a plain lambda to defer stuff?

no, that isn’t right. If it’s a credentials object you are after, create a Provider<Credentials> and a receiver property Property<Credentials> on the extensions. A Provider is a specific interface in the Gradle API; more context available here.

im a bit lost. Credentials is my type or gradle type

Something like this (Kotlin): Extension:

public abstract class AppAutomateUploadExtension {
    @get:Input
    public abstract val credentials : Property<Credentials>
}

val credProvider = providers.provider {
            val props = readFile(...)
            return Credentials(props["username"], props["password"])
        }

…Credentials can be your type, if that exists and is what you are modelling.

interesting but isnt that the same as I did?

Not the same. It’s a Property/Provider, which is the key difference. That represents a supplier/factory for getting the credentials at a later time. That is then passed to where the credentials are needed (presumably a task), which then resolves the provider via

.get

.

yea but I still want to be idiomatic, so Provider is the way to go right?

Yes. All the values on your extension should be Property objects (or List/Set/MapProperty as needed), as should all the attributes on your tasks.

yes Ill only resolve those in execution phase. Now I’m just figuring out if my api or the

providers.provider

factory is nicer

the Providers API also offers mapping via

.map()

. Say you have a Provider<Map<String,String>> and want to pass one specific map entry into a task - you can go

prop.map { this["username"] }

to turn that into a Provider<String>. also available are conventions (defaults) for properties via

.convention()

.

yea, interesting that I never heard of this yet. usually its just file handles

no worries, hope it works out for you.

if you use

providers

, then

tasks.register("myTask") {
    val credentials = project.providers.credentials(PasswordCredentials::class, name)
    doLast {
        val credentials = credentials.get()
        println("${credentials.username}:${credentials.password}")
    }
}

lets you provide it via any of

# gradle.properties
myTaskUsername = foo
myTaskPassword = bar

or

./gradlew myTask -PmyTaskUsername=foo -PmyTaskPassword=bar

or

env ORG_GRADLE_PROJECT_myTaskUsername=foo ORG_GRADLE_PROJECT_myTaskPassword=bar ./gradlew myTask

without requiring credentials if the task isn't run