Відео

Short answer: Yes - ua-cam.com/video/Ajs8pTbg8as/v-deo.html Long answer: If you go through the complete playlist you will learn about the fundamental Gradle concepts and certain details on how to using Gradle for Java projects. Depending on what you want to do, it might be "too much" in some places and "too abstract" in others. But it depends on what you expect and what you plan to do with Gradle. I also have: A course on Udemy (💲) going through things step-by-step in a lower pace for a typical Java project setup. www.udemy.com/course/modern-gradle-fundamentals/?referralCode=3AC1B96C0EBE6F4FBE6E An example on GitHub that shows a complete project (also with links to the videos). github.com/jjohannes/gradle-project-setup-howto

This is a good question, because this is the one thing that is quite difficult to centralize. This is, because the repositories are needed very early. Before Gradle can load the *build configuration* itself, it must load plugins from your repository. But if repositories are defined as part of the *build configuration* - there is a chicken-egg problem. Lets first summarize what I usually do in this video series and which you can find in my example project: github.com/jjohannes/gradle-project-setup-howto We have three places: (1) *gradle/plugins/build.gradle* (or 'my-build-logic/settings.gradle' in the video examples) Here we define the repositories for Gradle to **build** the convention plugins. This is independent, because it is treated as an independent project by Gradle. (2) *pluginManagement* in *settings.gradle* Here we define the repositories for Gradle to **use** all plugins. This is usually the same as above. But because this is a different project/context the definitions are not reused. (Maybe there will be some feature in a future Gradle version...) (3) *dependencyManagement* in *settings.gradle* Here we define the repositories to find other libraries we use. This may be different than the above (e.g mavenCentral while the above are gradlePluginPortal) but in your case, it is the same again. Usually, I just accept that there is some repetition. But there is at least one trick that you can use, which is putting the information you want to share into a separate file. For instance, you can create a file that just contains your Nexus URL: *gradle/nexus.txt* (content e.g.: plugins.gradle.org/m2/) And then, in all the three places above, you get the URL from the file: *repositories.maven(providers.fileContents(layout.projectDirectory.file("../nexus.txt")).asText.get().trim())*

Hi. A plugin publication consists of multiple "components" that are published by different tasks. You should not use these tasks individually as they are all connected. If you publish to your own repository (that you configured in publishing.repositories {}) usually you can call *gradle publish* to publish everything at once. That will publish: - The JAR with *all* plugins in it to *my/group/plugin-project-name/1.0/plugin-project-name-1.0.jar* - A so-called "Marker POM" for each plugin to *my/plugin/id/my.plugin.id.gradle.plugin/1.0/my.plugin.id.gradle.plugin-1.0.pom* See also the section on this in the Gradle docs: docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers The "Marker POMs" do not contain your plugins. They are only there so that Gradle can find plugins if a user does directly want to use them via the *id("my.plugin.id") version "1.0"* notation in a build file. Because Gradle does not know the *group* of the Jar in this case, it uses the marker to indirectly get to it. That's why markers and the corresponding JAR have the same version. If you want to publish plugins with different versions, they need to be packaged in separate Jars. You can achieve that by defining plugins in different subprojects that you publish individually. E.g. *gradle :my-plugin-a:publish* / *gradle :my-plugin-b:publish*

@@jjohannes Wow, great explanation, thanks a lot for taking the time to respond!

Thank you! Regarding the question: It's quite straight forward. The *checkstyle* plugin is aware of *source sets* and will register a task to check *testFixtures* automatically, which is called *checkstyleTestFixtures* . After you use the plugin - *id("checkstyle")* - you can run: *gradle checkstyleTestFixtures* What the plugin does not do is automatically adding that task to the *check* lifecycle. Which is probably what you are looking for. You can do this: *tasks.check { dependsOn(tasks.named("checkstyleTestFixtures")) }* Then it runs as part of *gradle check*

@@jjohannes that worked, ended up finding the new tasks by accident while attempting a fix, so thanks for confirming it!!

The output looks like the *app* project only has the *base* plugin but no java/application plugin. Then you get the lifecycle tasks - *assemble* *check* *build* - but nothing is linked to them. Please check: - Which plugin do you apply in *my-project/app/build.gradle* ? Is it *id("my-java-application")* ? If not, add it. If you have it... - ...check your *my-build-logic/java-plugins/src/main/kotlin/my-java-application.gradle.kts* . Does it apply the *id("application")* plugin?

​@@jjohannes When I applied "base" plugin to my-project/app/build.gradle and applied "java-library" and "org.jetbrains.kotlin.jvm" plugins to my-build-logic/java-plugins/src/main/kotlin/my-java-application.gradle.kts ,I got these results. Actually, I did the same things from the first video to where you applied the "base" plugin. By the way, I haven't declared anything other than the "base" plugin in the "app"'s build file yet. But somehow it produces an output as if I added dependency. By the way, if you want to take a look, I sent you the code I wrote on Udemy.

@@hsnclk1985 IIUC, your question is why you see all the *> Task :my-build-logic:java-plugins:...* tasks although you only build the app project that does not use any of the plugins in *:my-build-logic:java-plugins* . The reason is that the plugins are required at configuration time of the *whole my-project build* . In other words, *:my-build-logic:java-plugins* is a dependency of the whole build and not of individual subprojects like *app* . In other places of the build you use some of the plugins. Which are in *data-model/build.gradle.kts* and *business-logic/build.gradle.kts* . If these two files would not use any of the plugin (e.g. if you remove id("my-java-library") from these files), you will no longer see the *:my-build-logic:java-plugins* tasks running.

> but the problem here is that providing --rerun to lifecycle task won't affect the actual test tasks doing real job. Yes this is a shortcoming of Gradle. I think such a feature is missing. You have similar issues with other task-specific options like '--test'. The best "workaround" I know is to add a "-P" parameter (gradle property) for this yourself. Then users can do something like this: *./gradlew :testAll -PrerunTests* Then you would configure your test tasks to pick up the parameter. Something like: *tasks.withType<Test>().configureEach {* *if (providers.gradleProperty("rerunTests").isPresent) { inputs.property("time", Date().time) }* *}* (IntelliJ IDEA does something similar in the background when you press the test run button in the IDE.)

Whether something will be part of the configuration of a build invocation is decided by Gradle. In general, what you configure will be used if the "thing" you configured is used. For example, if you configure the *runtimeClasspath* , the configuration of it will be performed (i.e. the closure will be executed), before the *runtimeClasspath* is used if you run a build that uses the *runtimeClasspath* .

This is a forward reference to the next video in the series about *Plugins* ua-cam.com/video/N95YI-szd78/v-deo.html In that video, I continue with the same example and show how to move build configuration from all *build.gradle* files into plugins.

That's a very good question. The best solution I know of is generating a timestamp yourself and set that as version. For example: *version = "1.0-${SimpleDateFormat("yyyyMMddHHmmssSSS").format(Date())}"* The tricky part is to use the same timestamp for the whole build if you publish multiple modules. The most compact way to achieve that is to set the version in the *root project* and then use that in all the subprojects. Add a *build.gradle.kts* to the root: *import java.text.SimpleDateFormat* *import java.util.Date* *version = "1.0-${SimpleDateFormat("yyyyMMddHHmmssSSS").format(Date())}"* Use that version in all the subprojects, e.g. in *my-java-base.gradle.kts* for the example in this video: *group = "org.example.my-app"* *version = rootProject.version* I shared a full example here: github.com/jjohannes/gradle-demos/tree/main/publish-with-timestamp-version

@@jjohannes thanks a lot it worked for me the only part needed is my nexus policy allow version to publish with 1.0.0-SNAPSHOT what changes need to do in your script so that every time it's incremented

I think I can answer this question myself now. Please correct me if I am wrong, but based on what I learnt from the docs, the most idiomatic way would be to create a "configureJibForProdImagetask" where I 1) find subproject -> 2) find Jib extension on subproject -> and configure it as needed in doLast {} block of this special task. Now in my lifecycle task I should first dependsOn(configureJibForProdImagetask) and then depend on actionable Jib task. Works as expected! (but not compatible with configuration cache though :( )

@@kirillgavrilov9681 Unfortunately, there is no real "good" solution for this as far as I know. I would try to do this in the configuration of the lifecycle task directly, instead of using 'doLast' or 'doFirst'. Like this (here I use Test.debug as an example of an @Option): *tasks.register("myLifecycle") {* *dependsOn(tasks.named("test"))* *tasks.getByName<Test>("test") { this.debug = true }* *}* As far as I know, it is not really recommended to configure one task from another. But I think in this case it is still the best option. The trick is that as long as you use "lazy task configuration" (register/named), the configuration block is only executed if you call "myLifecycle". Note that *getByName* theoretically breaks "lazy task configuration" for the "test" task (in contrast to *named* which won't work here). But since you add the dependsOn anyway, it is not a problem in practice. Would be interested to know if this works for you.

​@@jjohannes Hi! Thank you for your reply. > I would try to do this in the configuration of the lifecycle task directly, instead of using 'doLast' or 'doFirst' > getByName theoretically breaks "lazy task configuration" for the "test" task (in contrast to named which won't work here). But since you add the dependsOn anyway, it is not a problem in practice. Yes, this works for me and I simplified my solution with "configureXXX" task down to simply using configuration-block of 1st task to configure 2nd task. Introducing additional "configuration"-task does not seem to provide any benefits here. I need to access a target plugin's DSL in target subproject, which is not lazy and not configuration-cache friendly (which is explicitly said in docs), but I do not see a better choice here. Laziness is not a problem: as you said, there is a dependsOn anyway. CC would be nice to have, but Gradle docs explicitly say that configuring one task from another is not CC-friendly. I would be happy to work with some lazy Gradle properties providers to configure behavior of one task from another and avoid 'getByName', but such properties are not exposed by the target plugin, so I have to access subproject and plugin's extension DSL to achieve the same effect as using `--option` allows. Honestly, now I'm struggling to understand the recommendation to introduce additional `configureXXX` task instead of doing doFirst from this section of the documentation: docs.gradle.org/8.7/userguide/common_caching_problems.html#custom_actions I understood that doFirts changes are hidden for UP-TO-DATE and build cache checks. But why simply not to configure manifest attributes inside of tasks.named("test) {} lazy block? Why somebody might want to use "doFirts" for configuration, while there is a task's configuration block getting executed BEFORE actual task action begins? 🤔

​@@kirillgavrilov9681 > CC would be nice to have, but Gradle docs explicitly say that configuring one task from another is not CC-friendly. Have you tested this? Is this always the case or just a general recommendation (which does not apply for this specific use case). Because I think this case should still work with CC (I very much hope). > Why somebody might want to use "doFirst" for configuration, while there is a task's configuration block getting executed BEFORE actual task action begins? I have used that for exactly the reason to hide something from UP-TO-DATE. An example is that you want to add a timestamp as attribute. But only add that if something else changed. Otherwise you are fine with reusing the previous Jar (with the previous time stamp). (If you really need timestamps in manifests is another question :) - but I have seen projects that insisted to have it.)

What you describe can happen, if: (1) You define plugins in an included build logic build - *my-build-logic/java-plugins/src/main/kotlin/*.gradle.kts* in the example (2) Do *not use any* of the plugins in your main build - non of your *build.gradle.kts* has one of the plugin in the *plugins { }* block Gradle only builds plugins if they are used, otherwise the plugins build (my-build-logic in the example) is not used. Even if you run a complete *build* of the main project (./gradlew build). As a consequence, certain files generated by Gradle may be missing that IntelliJ relies on. The "command + f9" in IntelliJ might do more. Something like the equivalent to this from command line: ./gradlew build cd ../my-build-logic ../my-project/gradlew build That is, building you main project (my-project) and *explicitly* building the build logic project (my-build-logic) as well.

@@jjohannes I understood very well what you said at the beginning, except for what you did in the command line. 1) ./gradlew build (In the first command I assume I'm in my-project. By doing this, I build all connected projects and plugins.) 2) cd ../my-build-logic (now I am in my-build-logic folder) 3) ../my-project/gradlew build (In this command, if I understand correctly, the gradlew script in the "my-project" folder is called from "my-build-logic". I don't understand what you did here.) By the way, I should point out that. I use only one gradlew script to ensure version consistency, which in turn is under my-project folder. So there is no gradlew under my-build-logic folder. I hope I understood the usage of gradlew correctly.

Hi @hsnclk1985. I talk about this here: ua-cam.com/video/N95YI-szd78/v-deo.html (3:13). When you have a separate *build logic* build/project, you use Gradle's dependency management mechanisms as in any other Gradle project. External plugins, or better the Jars containing the plugins, then become dependencies of that project which you define in the *build.gradle.kts of the build logic* project. In this example I have: dependencies { implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.20") } The "short notation" *id("org.jetbrains.kotlin.jvm") version "1.8.20"* that I show in the beginning of the video can be utilized to use external plugins directly in a build.gradle.kts file of your project *without a build logic* project.

@@jjohannes I'm not sure we're talking about the same thing. I had asked about the gradle script in the kotlin folder. I mean, my-java-library.gradle.kts file. Here, you wrote the Kotlin plugin declaration in the plugins code block without specifying the version number. Like this, id("org.jetbrains.kotlin.jvm"), not like this, id("org.jetbrains.kotlin.jvm") version "1.8.20"

@@hsnclk1985 Yes that's what I am talking about. You have to use *id("org.jetbrains.kotlin.jvm")* (without version) inside *java-plugins/src/main/kotin/*.gradle.kts* files. Instead, you define a dependency to the Jar containing the plugin in *java-plugins/build.gradle.kts* . In this case: *dependencies { implementation("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.20") }*

@@jjohannes My confusion is gone. I really appreciate it.

Hi. This is a very good question/topic. There are (edge) cases where the "legacy" mechanism is useful. I don't think that it will ever be removed completely. In Kotlin DSL, it is mainly discouraged because you loose most of the DSL niceness by not getting accessors generated. In general, I would say the idiomatic approach is to always apply all plugins and then conditionally let plugins not do anything. However, if a plugin is not written in a way that supports such a "no-op" state, there may be no way to achieve this. For instance, in your example of the *jacoco* plugin, you could always apply the plugin and then deactivate the instrumentation conditionally. But, while that is possible I believe, there is no simple on/off syntax for that provided by the plugin. And then there are cases where there is no other option. For example, I recently updated a build to be compatible with the Configuration Cache (CC). But the build uses the *com.google.cloud.artifactregistry.gradle-plugin* which is not CC compatible (github.com/GoogleCloudPlatform/artifact-registry-maven-tools/issues/85). So we decided to run just the publishing builds with *--no-configuration-cache* as the plugin is not needed in daily development. However, as just applying the plugin already breaks CC, I ended up doing this: *if (!serviceOf<BuildFeatures>().configurationCache.active.get()) {* *apply(plugin = "com.google.cloud.artifactregistry.gradle-plugin")* *}*

Hi @Omega3131, it's a bit hard for me to understand your full setup from this comment. So I share a few pointers that I hope can help you figure out the issues you are having: For using plugins from a repository, you should define the repository in *pluginManagement { repositories.maven(...) }* (not dependencyResolutionManagement, which is for repositories that contain libraries you want to use in your code). Also, instead of publishing to mavenLocal(), you can directly include the plugin build using *pluginManagement { includeBuild(...) }* See also my explanation here: ua-cam.com/video/Ajs8pTbg8as/v-deo.html I wrote this guide on Gradle plugins that shows how to write and publish them (using different languages). Maybe that helps to clarify some things: github.com/jjohannes/gradle-plugins-howto Regarding the group (com.my...): This can be confusing indeed. In Gradle, plugins have two things: (1) the *Plugin ID* and (2) The *group* + *name* coordinates when you publish. (1) is a specific Gradle plugins concept, (2) is the general identification of components in Maven repositories as explained in this video (technically, Gradle plugins are Jars with class files and metadata inside like any other Java library). When you use the Kotlin DSL to write plugins, the *file name* is the *Plugin ID* . The *group* is whatever you define in the *build.gradle.kts* of your plugins build. If you want different groups/versions, you need to split up your plugins into multiple Gradle (sub)projects. When you publish, one Jar can contain multiple plugins and then these all have the same "group" and "version". In addition, Gradle publishes a so-called "Marker" for each plugin. This is only a POM file. Here the group is computed by Gradle based on the plugin ID. This is so that Gradle can find plugins in repositories only by ID. E.g., if you write *plugins { id("my.published.plugin") version "1.0" }* Gradle can find the plugin in the repository although you never give it the "group" + "name" for the Jar file that contains the plugin. See: docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers The Markers *do not* contain the plugins. They only point Gradle to the Jar that contains plugins and several markers can point to the same Jar with multiple plugins inside.

@@jjohannesThanks! The naming really is confusing. I will try to create an issue on your repo with my setup.

If it is not "too expensive" in your case, I would use/migrate to Kotlin DSL. In particular, when you use IntelliJ IDEA as primary IDE. The tool support (auto-completion, suggestions, early error detection) is much better. If you already use Groovy and want to stick with it for particular reasons, you can do that. It is "just" the language on top of Gradle's API. You can use all Gradle features in both languages. See also my video on the topic: ua-cam.com/video/pKsn2eZWQK0/v-deo.html

Yes, I think learning the current best practices (which I show in my videos) is helpful to understand the fundamental workings of Gradle's systems. And as it is also a goal of my videos to explain these systems, they should be helpful for you. Many of these systems exist since Gradle 1. For the "basics" I would recommend watching at least Episodes 1-10 (you might not need to understand everything in detail). For generally reading "old" Groovy scripts, the background I explain on the Groovy and Kotlin DSLs in Episode 24 should be helpful: ua-cam.com/video/pKsn2eZWQK0/v-deo.html

> when we apply the *kotlin-dsl* plugin to the *java-plugins* subfolder within the *my-build-logic* folder, we are declaring that this project will have the Kotlin source tree (that is, *src/main/kotlin* ). Am I right? Yes that is correct. However, you observed correctly that Gradle does not create *src/...* folders automatically. This is is not clearly shown in this video. What you get however, is that IntelliJ reads the information from Gradle that *src/main/kotlin* is a folder you might want to create. If you right-click and select *New > Directory* it will offer you to create *src/main/kotlin* among others with one click.

@@jjohannes Thank you, Jendrik. I understood

No you don't. In the example, I would put the wrapper into the *my-project* folder. From there you can then import into IDEA or run builds. Things in *my-build-logic* will be included in these builds. As there is no separate Gradle process for the included builds, it will always use the same Gradle version you started the main build with. In a real-life project, it is common to have the project itself together with the wrapper in the root of a git repository. And then have the build-logic in some subfolder: for example *gradle/plugins* I.e. *settings.gradle.kts* is in the root and contains a *pluginsManagement { includeBuild("gradle/plugins") }*

@@jjohannes Thanks. If I understand correctly, the wrapper in the main project (I mean, my-project) compiles other projects via the include statement. And in this way, each project included in the main project has the same version.

Yes. Technically, each "block" is a Java function call that is executed during Gradle's "configuration phase" where Gradle builds up a model of your project in memory. Technically, this model are Java objects. Sometimes, the "blocks" do not look like function calls, but this is only because of "syntactic sugar" from Kotlin/Groovy. For example, the following are equivalent: *setGroup("org.example")* // working in Java *group = "org.examle"* // working in Groovy/Kotlin because you can use "=" for "set" methods *tasks.named("build", t -> t.dependsOn("myTask"))* // working in Java, second argument is a function call (lambda/closure) *tasks.named("build") { dependsOn("myTask") }* // working in Groovy/Kotlin because if last method argument is a lambda, you can use *{ }* notation The Java methods on the *Project* interface are always available: docs.gradle.org/current/javadoc/org/gradle/api/Project.html And methods on other interfaces your reach from there like *TaskContainer* or *Task* etc. Then there are additional methods added by plugins through extensions ( ua-cam.com/video/wrgyUKC7vOY/v-deo.htmlm29s ). Here Gradle uses code generation to create Kotlin extension functions ( kotlinlang.org/docs/extensions.html ) to dynamically add methods which do not exist on the Java interfaces. (In the case of the Groovy DSL something similar, it's done through reflection.) I explain this more in the videos on the DSLs and using Java to configure Gradle: - ua-cam.com/video/pKsn2eZWQK0/v-deo.html - ua-cam.com/video/XnVZdMROVG8/v-deo.html

Thank you for your interest. You can finde the examples from all my videos in this GitHub repository: github.com/jjohannes/understanding-gradle Specifically, the example for this video is here: github.com/jjohannes/understanding-gradle/tree/main/06_Configuring_Task_Inputs_And_Outputs My goal is to show current and future-proof APIs and language constructs in all videos. Sometimes (not here) I show very recent additions in the second part of a video where it may happen that some detail changes in a new Gradle version. In these cases, I update the corresponding examples on GitHub. They always work with the latest Gradle release.

Test suites are convenience introduced recently to ease the setup of new "test sets". In most scenarios, I recommend to use them as they make custom test configuration more compact. You often can do in one line, what you would otherwise have to do in several places (source set, task, dependencies). I show this in detail in this video: ua-cam.com/video/7f_gBvGQN_0/v-deo.html That being said, it's a convenience on top of otherwise public APIs. So you can do everything without it. In the context of this video, you need to use them if you also want to use *org.gradlex.java-module-testing* to ease the Module Path setup. That plugin builds on top of the test suite APIs.

I don't know how Spring loads the *application.properties* internally. But I assume that it use the *classpath* to find the file in it. If you have multiple *application.properties* files which are not inside a package (in subfolders of resources), Java's mechanism to load resources from the classpath will return the first file it finds. The others can't be accessed at all. Which file is the first, depends on how things are ordered by Gradle when the tests are executed. In your example, the file from "testFixtures A" probably is found first. In general, you should avoid having multiple files with the same name in the same location on the classpath so that the behavior of the application does not depend on classpath order. I made a video on that topic: ua-cam.com/video/KocTqF0hO_8/v-deo.html

The *org.javamodularity.moduleplugin* was started by the community before there was any support for the Module System in Gradle itself in Gradle 3, 4, 5 or 6. It re-configures all the tasks that require special treatment (JavaCompile, Test, JavaDoc, Run) to work with the *--module-path* . As Gradle 7 or 8 has *--module-path* support built-in (since 6.4) the plugin is not needed anymore in general. It has some configuration options that Gradle itself does not offer. Maybe one of these is a reason to still use it. But it requires you to turn off Gradle's built-in support and thus does not work well together with other plugins in this area - like the GradleX plugins (github.com/gradlex-org/extra-java-module-info) I am working on. From my experience by now, in most cases it only makes sense to use the Module System, if you fully use it as originally intended. Which means all Jars that you use have a *module-info.java* - and if you need Jars that do not have that, then you patch them. This is what the *extra-java-module-info* does. The *org.javamodularity.moduleplugin* does not have such functionality.

Sorry if you are having trouble following my videos. If the stile does not suite you, here are some other resources you could check out: - www.youtube.com/@TomGregoryTech has many good videos on Gradle from a possibly more "beginner friendly" perspective - Gradle Inc. sometimes offers free online courses: gradle.org/courses - I have a course on Udemy, that covers the beginner topics with more details and slower pace: www.udemy.com/course/modern-gradle-fundamentals/?referralCode=3AC1B96C0EBE6F4FBE6E My Udemy course is not free but there are often discounts. If you are genuinely interested, but can't afford it, please drop me a mail. Regarding the samples on GitHub (github.com/jjohannes/understanding-gradle/tree/main/05_Lifecycle_Tasks). They usually cover what I show in the video. Due to the dynamics of the video (I sometimes show alternative approaches) they may differ a bit or include alternatives in commented-out sections. They also may include additional files so that they make up a complete Gradle project. For each of these files, there is a video explaining them - in particular Episodes 1, 2 and 3 (settings file, build files, plugins). In some cases I extended the examples later after good discussions in these comments. In this case, I added the "lifecycleTasks" task after @Blundelll asked "How can you tell if a task is a Lifecycle task or an Actionable task?" (see the corresponding comment).

Are you getting this error when importing the following project in an IDE? github.com/jjohannes/understanding-gradle/tree/main/02_The_Build_Files/my-project Could you share more details about what you are trying to achieve? I haven't seen this error in connection with the example from this video yet.

Hi Kirill. Thank you. That's a good question. You are right that ":dependencies" only looks at the metadata. It's a common point of confusion that the dependency resolution is done in two phases: (1) looking at metadata and resolving conflicts (2) downloading the actual artifacts (if needed). I plan to do another video on that topic at some point. To your question: There is no built-in task in Gradle that "resolves all configurations". And I think this is one of the topics where no consensus has been reached yet in the community what the best solution is. You probably also do not need to resolve "all" configurations but only the ones that you actually use (which would be "*RuntimeClasspath" and "*CompileClasspath" in a standard Java project). Two solutions I would probably use: 1. Run a build that would do everything the real build does in Dry Run mode: *gradle build --dry-run* As this computes the inputs of all tasks, it also resolves the dependencies. Unfortunately --dry-run is broken for composite builds (github.com/gradle/gradle/issues/2517). 2. Write your own task that does the resolving. It should be enough to have an "empty" task that has the configurations it needs as input. E.g.: *tasks.register("resolveAll") {* *configurations.forEach {* *if (it.isCanBeResolved) {* // or just selected configurations *inputs.files(it)* *}* *}* *doLast { }* // Have at least on action to trigger the download *}*

The approach looks correct. Which error did you get? If it is only an issue in the IDE, you can also define the type of the task as part of 'named': *tasks.named('wrapper', Wrapper) { ... }* *task wrapper(type: Wrapper) { ... }* is one of the "convenience" notations introduced in Gradle 1 for Groovy DSL. It's likely to be deprecated in the future. It is the same as doing *task.getByName('wrapper', Wrapper) { ... }* or (if the task does not exist) *task.create('wrapper', Wrapper) { ... }* . In your case, it might create the task if it does not yet exists for whatever reason, but that's probably not what you want. Which is one of the reasons I think this notation is a bit "too magical".

@@jjohannesUnderstood, thanks! The problems was that I was doing this under a subproject configuration instead of the parent.

The *libs.versions.toml* file is a Catalog, which means - put simply - it is only a collection of Strings that you can conveniently access in all your *build.gradle(.kts)* files. If you want to exclude a dependency - lets say *org.example:foo* - you could add this coordinates String to the catalog: *[libraries]* *foo={module="org.example:foo"}* Then you can refer to that via *libs.foo* somewhere in your build files to exclude the dependency. Note that the notation for this is a bit complicated right now. See this feature request: github.com/gradle/gradle/issues/20274 dependencies { implementation(libs.foo) { exclude(group = libs.bar.get().group, module = libs.bar.get().name) } } In general, instead of using *exclude()* you may also consider using a *component metadata rule* to remove a dependency globally: ua-cam.com/video/5g20kbbqBFk/v-deo.htmlm18s

In Android projects, you have different runtime classpaths - one for each BuildType+Flavor combination. A single *runtimeClasspath* (as in plain Java projects) does not exist. That's what the (quite misleading) error message means to say. You could use, for example, *releaseRuntimeClasspath* and maybe also add the corresponding classpaths for other flavors to the list. If you run *gradle :app:dependencies* it should show you all the existing Configurations which you can use to figure out which RuntimeClasspaths your have. dependencyCheck { scanConfigurations = listOf("releaseRuntimeClasspath") } In a working example: github.com/jjohannes/gradle-project-setup-howto/blob/android/gradle/plugins/android-application-plugins/src/main/kotlin/org.example.android-application.gradle.kts#L43-L46

@@jjohannes Thank you. I configured the scanConfiguration by hardcoding one of my product flavor, e.g. "orange". This isn't optimal for maintenance - it could just pick the first. dependencyCheck { scanConfigurations = ["orangeReleaseRuntimeClasspath"] nvd { apiKey = "some-key" } } This made the "An NVD API Key was not provided - it is highly recommended to use an NVD API key as the update can take a VERY long time without an API Key" disappear but still the "dependencyCheckAnalyze" task runs for 30 minutes already without progress. Is it working for you? Btw. my project is open source if you want to try yourself.

@@tobiaspreuss I suspect this to be an environment issue. I remember that I sometimes had issues that it took long time on the first run, because it is downloading a lot of data from the CVE database. And the connection was not very stable sometimes. You can try setting "autoUpdate = false" temporarily to see if that speed things up. But you probably do not want that permanently. TBH I have not actively (re)configured the plugin for some time now. There are quite a lot of options.

@@jjohannes Thanks. Yes with "autoUpdate = false" the task finished successfully.

Thank you for the feedback and the suggestion! I put the topic "Custom Gradle Distributions" on my list.

That's a large question. :) I haven't really done anything on this topic in my videos. But it is an interesting topic, which is now on my list for future episodes! I think there was always the idea that a *JAR* is a ready-to-use software component that you can plug into your software without modifying it. It contains, for example, all meta information (like license information) and may be signed. Which are all interesting aspects if you use 3rd party components (like open source components from Maven Central). With the Java Module System (see ua-cam.com/video/X9u1taDwLSA/v-deo.html) this idea became even stronger. Now each Jar has meta-information (module-info.class) that is actively used by the Java runtime. With this in mind, it seems natural that all Jars that make up an application are delivered as they are. Without the Java Module System however, it is also a common approach to re-package everything into one *JAR* . In Gradle, the Shadow Plugin (imperceptiblethoughts.com/shadow) is quite popular that offers some convenient functionality to make sure no important metadata is lost when combining Jars. And many framework specific plugins - like Spring Boot or Micronaut - also come with their own packaging support. But in the end, there are many options to do this and my impression is that there is not the "one right way" how to package a Java-based application at the moment. With the Java Module System, the Java tools themselves contain the *jlink* and *jpackage* (docs.oracle.com/en/java/javase/21/jpackage/packaging-overview.html) commands. These are for creating a package (basically again a ZIP or an Installer) which contains a complete application for a certain Operating System - including the Java runtime. I think this is where things are heading on the long run.

@@jjohannes so basically if my code require 2 or more dependencies that I will use them in the source code, in which they came in the form of 2 separate .jar files. If it needs to be packaged for release distribution to the user it needs to be repackaged again into single .jar file otherwise it will be called fat jar if not mistaken. But the manifest file is important too, it cannot be lost because it specify the package name of that dependency. If the two jars, need to be ripped apart and merge again together the package name will change. But for now I think I want to learn how to write the `run` task for debugging. Otherwise I have to specify manually the `classpath` to the JVM. Only just recently I know that the consumer code i.e the .class code that contains the main class can be linked directly by using class path parameter. Meaning it doesn't have to be in a .jar file. And only recently, I know the `application` gradle plugin is useful to set the `Main-class` attribute for the .jar file.

Thank you! That's a good suggestion, which I did not have on my topics list yet. Might even be a good one for one of the next episodes.

​@@jjohannes it would be extremely useful 😍