Yes, that’s what I did. Sorry it did not look like in my image I took.
Ah, ok then.
Then you just did forget to create the configuration.
Also the text seemed to suggest you added it outside, not inside. 
I would like to do that, but with my lack of experience, I could not contribute anything other than “I barely understand the page”. Therefore I first need to learn more about this. If possible, I’ll try to contribute.
I said “issue”, for that it is fine to just say “this docs are unclear”. But a PR that improves the docs would of course even be nicer, but not what I meant.
Are they not false by default but instead null?
They are boolean, they cannot be null.
They are all true by default and thus create a legacy configuration that shouldn’t be used.
As I already said earlier, this is due to backwards compatibility.
What issue would it oppose if it were consumable, resolvable or visible? What is each properties purpose in the sense of a configuration?
I just explained it in detail in my last answer.
If you have further questions, maybe read it again.
And if you then have further questions, feel free to ask them, but please bit more targetedly.
With the question you just asked, I could just copy & paste what I wrote above.
Why is “resolving” a concept or what purpose does it have?
I don’t understand the question.
Why should it not be a concept?
And the purpose is, to resolve the dependencies and their transitive dependencies, and resolve version conflicts, and so on.
Resolving is a very broad and generic term, it does not further explain what really happens.
The term on its own maybe not, but in the context it is pretty focussed and clearly defined.
There is even a whole page in the user manual for the topic: Understanding dependency resolution.
Whats the use of a configuration that can not be consumed or which is invisible? What is the reason there is a property for visibility and consumability? If it is not visible, it implies I can’t consume it so why do I need to explicitly set isCanBeConsumable to false, and why does the property exist if isVisible exists?
Again, I already explained the different roles configurations can have and what they are for in my last post.
And “invisible” you always want.
It is a badly named flag of a legacy mechanism that shouldn’t be used anymore anyway and also is just true by default for backwards compatibility.
Thus setting the configuration to “invisible” does not mean you do not see it or cannot consume it and it does not have to be “visible” for being able to consume it.
You mention For dependencyScope that would be but what is meant by dependencyScope? You show a code snipped for a configuration. I thought its a configuration for the current Gradle project, not a dependency. What is a scope of a dependency or why are dependencies scoped? Same questions for resolvable .
Again, I explained the different roles a configuration can have above and what they are for, so what exactly is unclear? Why do you think a dependency has a scope I did not say anything implying that. What you talk about is a configuration with role “dependencyScope”, which is the name of the new incubating convenience methods you don’t want to use. It means it is neither resolvable, nor consumable, but declarable, meaning you declare dependencies for it. Configurations like implementation or runtimeOnly or compileOnly or api are “dependency scope” as those are the configurations where you declare dependencies on, not the ones other projects consume nor the ones you use to resolve for example a full classpath from those definitions.
You create a extensionDexFiles property but I never have any more than one dex file per Android project. Why is it called “extensionDexFiles ”?
You can also name it “honeypot”, or “theFlash”, the name doesn’t matter, name it however you like it. But even if you only have one dex file per project, as soon as you depend on two projects, this configuration contains the dex files of both projects, hence the ...Files.
On a side note, why is the function called creating instead of create or new ?
new is a keyword, you cannot name a function that easily.
There is another one called create that you give a name by string as I also showed you above.
But for the property delegation where the name is taken from the variable name by creating reads much better than by create. That’s at least what I guess why they named it that. If you want a definite answer, ask the one who invented it. I’m just a user like you.
Why was no regular constructor used? Is this a convention in Gradle?
Because you now simply create an instance, you add an instance to the configurations container and yes, it’s always like that with domain object containers in Gradle. In built-in ones, as well as in well designed 3rd party plugins.
Also, most domain objects you could not or at least should not construct yourself ever, but always let Gradle do it, because you can save quite some boilerplate by Gradle magic that implements various methods and injects various things for you and also makes the classes automatically implement ExtensionAware, which is why you can practically everywhere add extensions or set extra properties (even if you shouldn’t do the latter in most cases). But these are topics you should not care about too much unless you develop custom plugins.
In addition to that this API leverages delegated properties to create a name for the configuration, but the following API doesn’t, which is unusually inconsistent:
I fully agree and are pretty unlucky about their reaction: Kotlin DSL property delegates for fixed-type configuration factory methods · Issue #27204 · gradle/gradle · GitHub, but 
.
But why is this something exposed to the user? Why does it not resolve for me and instead I have to resolve it myself? What is the purpose of exposing this functionality to the user?
I don’t understand the question, you do not resolve anything yourself.
You create a configuration whose role is to be resolved and when you tell it “get me the files” it does its work.
Without “exposing this functionality to the user” you could not get any files from the configuration and they were useless at all, so I really don’t get the question.
What does it mean that a “build requests a configuration”?
That was maybe expressed a bit misleading. What I meant was “projects in the same build” as well as “projects in other builds”, the latter for example if you published the configuration as feature variant or use composite builds to combine multiple builds into one.
For me, a “build” is a process that can be executed in a project.
No, that’s wrong, that is “the execution of a build”.
A “build” is the entirety of the projects that you define / include in your settings script.
What does it mean to declare a dependency on a dependency scope? Is a dependency scope a collection of dependencies? Why can you depend on a collection of dependencies instead of just the dependencies directly?
Again, you do not depend on a “dependency scope”, you have a configuration with role “dependency scope” on which you declare dependencies like implementation("commons-io:commons-io:+") where implementation is the confiugration with role “dependency scope”. So yes, you could say a dependency scope is a collection of dependencies.
Why do I request the artifacts after a dependency resolution? What is the reason for this ordering or why does requesting an artifact require first resolving dependencies?
I start to think that you intentinally try to misinterpret every word I say. :-/
When you request the files of a resolvable configuration, resolution happens and after it finished you get the resulting files.
The reason for the ordering or why you cannot get an artifact without resolving first is obvious isn’t it?
You also cannot eat the meal before you have cooked.
creating is a function that is being called. Function calls in themselves are not highlighted as unused even if their return value is unused. For that reason, IntelliJ should not color it grey (unused).
We are not talking about creating, we are talking about extensionDex. Nowhere I said creating would be colored grey.
In addition to that the declared property is not used as visible in my previous screenshot as seen by the tooltip IntelliJ showed.
I start to think you didn’t properly read my answers.
Also that I already explained.
It is used and IntelliJ knows that.
by creating is using it.
This is just not a usage you get listed by “find usages”.
Complain to JetBrains if you think it should be listed.
Here is another example of a property I just declared that is not grey and (trust me) not used anywhere:
Well, seems there is a bug in the Kotlin IntelliJ Plugin then, report it.
On non-top-level it works as expected:
Unfortunately this is missuse of property delegates.
No, it is not.
You might consider it a misuse, but the Kotlin guys seem to not agree, as it works fine and also is not marked as unsued.
If you don’t want to use it like that, noone forces you to do so, you can always use the string-y methods.
I prefer using the delegates, then when I need them later, I already have them available and do not need to change from create to creating or have the name duplicated otherwise.
which I think exists exactly for the situation when you create a configuration and do not need it further anymore in your project.
You think wrongly. 
It exists, because there is more than Kotlin out there.
create exists longer than Kotlin even exists.
And there is also Groovy DSL, and also any other JVM language you could use to create configurations.,
creating is just a syntactic sugar that you can use in Kotlin code or Kotlin DSL if you want, but noone forces you to use the imho nicer-looking syntax.
Because the property is unused, I do not think it is correct practice to declare the property for that reason and instead the create function should have been used.
Well, you need to accept that we disagree in this point.
Use whatever makes you happy.
Besides that, all the configurations are used further.
extensionDex on the consumer side is used in the dependencies block for declaring dependencies and in the extensionDexFiles configuration to extend from it. extensionDexFiles is used as srcDir for the resources source directory set, extensionDex on the producer side should be used for the artifacts.add call imho.
Is it because it does not return a delegatable?
It has a different behavior, why should it be called the same?
But well, ask the one that invented it.
But as I said, it most probably has nothing to do with whether it returns a delegatable or not, because when it was added, not even Kotlin existed.
And for the delegated property it most probably simply reads better.
Of course, if you remove the dependency declaration, there is nothing to add.
Add what to what? The configuration to the resources?
Why should a configuration be added to the resources of the JAR? I want the dex to be added to the JAR not a “configuration”.
Again, do you do this intentionally?
You declare the configuration as srcDir for the resources source directory set of the main source set, and by doing so you add the contents of the resolution result for the configuration which are your dex files to the resources which are than packed to your jar.
In my case it jumped to completely different Gradle files.
A right, that’s an unfortunate effect of Gradle or the Kotlin compiler when compiling the build scripts only putting the name of the build script into it, not the full path. And if you then have multiple projects in your build and all their build scripts are called build.gradle.kts this happens.
I almost forgot about this, because due to various reasons (this issue being one of them) I at most call the root project build script build.gradle.kts if at all. All other build scripts I usually name after the project name, so for example foo/foo.gradle.kts. You can configure that in the settings script. It also makes it much easier to open a build script of a specific project if you have many projects. If you e.g. have a multi-project build with 100 projects and tell the IDE to open build.gradle.kts, that’s not a nice experience.
I not only want to just add them, I want to rename them as well. So in a zip file system they should appear in a subdirectory under different names.
You could control this for example on the producer side.
Or you could use an artifact transform to move the files into a subfolder on-the-fly, then it is the same for all resource consumers.
If you only do it on the processResources task, again it is only for that task and things that use its output, but not for things that use the resources or “allSource” on the source set.
If a configuration is a collection of files, why is the property singular.
That configuration has role “dependency scope”.
While technically it is a collection of files, semantically it is not.
It is a scope on which you declare dependencies.
An in that context the naming makes sense.
But as I said already, you can also name it supercalifragilisticexpialidocious
It is just a name, and naming is one of the hardest parts in software developement.
Just name it whatever you like, if you don’t like the conventions Gradle folks and me are following.
But this property is now plural. The property is a configuration and not a list of files
This is a configuration with role “resolvable” and thus it technically and now also semantically is a collection of files, the result of resolving the dependencies declared on it directly (which should not be done) or implicitly through the extensions it extends. If you only add one dependency to one Android subproject, it will still be a collection with only one file in it. If you do not declare any dependency it will be a collection with no entries. If you declare multiple dependencies, there will be multiple files in the result.
I inherited this deceiving naming from the official docs:
It is not at all deceiving, stop saying that.
It is absolutely appropriate and fitting perfectly semantically.
But again, name the configuration harryJamesPotter if you prefer, or maybe anastasiaRoseSteele, doesn’t matter, whatever makes you happy.
And also, the docs use plural sometimes only. Here they use singular once again:
Not really if you think about it. A “classpath” is a collection of files (and directories) and thus the plural of containing multiple files is merged into the name being a collection itself.
If you feel better with that style, use extensionDexDirectory (even if technically not fully correct it would then be semanitically correct, matching how you use it if you declare it as srcDir, and a singluar word), or extensionDexCollection.
I am not sure if I am missing something because I was not getting this exception previously.
That’s a Kotlin script quirk.
It allows forward reference.
You use extensionDex in line 22.
It is defined and initialized in line 32.
So when you use it in line 22 it works as Kotlin script allows such forward reference which would work if the code for example is in a lambda that is evaluated after line 32 got evaluated.
But in your case it is evaluated immediately and thus has a null value which is not ok as it has a non-nullable type.
This is like having a non-nullable lateinit var and using it before assigning a value.
Move line 32 up above the dependencies { ... } block and the error should be gone.
Thanks for making it through til here! I am learning with every of your responses, bit by bit.
