<!-- {"replyTargetCommentId":864113114,"teamCityBuildId":"44236014","teamCityBuildHeadRef":"a67d0a570f8f3cfbf1e514479fed337dcfb256c7","teamCityBuildStatus":"PENDING","replyApproveReviewId":null} --> OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

@big-guy ptal

Gradle adds --module-version when javaModuleVersion is set and the project has modular dependencies: https://github.com/gradle/gradle/blob/37911bb86d02d26a5d2ce3f23e01c0d767e3bb91/subprojects/language-java/src/main/java/org/gradle/api/internal/tasks/compile/JavaCompilerArgumentsBuilder.java#L277-L284

However, when the project has no dependencies, there is no module path, so --module-version is not added, and the module version is not recorded.

Expected Behavior

The module version is recorded in the descriptor when javaModuleVersion is set.

Current Behavior

The module version is not recorded when the project has no dependencies.

Context

JPMS offers a module version attribute for compiled module descriptors. The Gradle DSL allows setting the module version as described in the documentation: https://docs.gradle.org/current/userguide/java_library_plugin.html#declaring_module_versions

Steps to Reproduce

Create a project without any dependencies which has a module descriptor. Follow the documentation to add the module version using the javaModuleVersion property.

Reproducer project: https://github.com/A248/Gradle-Module-Version

1. Run gradle build
2. Run javap -v build/classes/java/main/module-info.class. Observe that the module is "module com.example". If a version was recorded, it would be "module [email protected]".

Javap output:

module com.example
  minor version: 0
  major version: 55
  flags: (0x8000) ACC_MODULE
  this_class: #1                          // "module-info"
  super_class: #0
  interfaces: 0, fields: 0, methods: 0, attributes: 2

3. Now, edit the build.gradle and uncomment the dependency on Gson. Rebuild using gradle clean build. It has to be a clean build.
4. Observe that the module version is now recorded.

New javap output:

module [email protected]
  minor version: 0
  major version: 55
  flags: (0x8000) ACC_MODULE
  this_class: #1                          // "module-info"
  super_class: #0
  interfaces: 0, fields: 0, methods: 0, attributes: 2

Your Environment

Gradle 7.0.2 Mac OS X 10.14.6 Build scan URL: https://scans.gradle.com/s/ctfzkwuleq7tk

<!-- {"replyTargetCommentId":864076953,"teamCityBuildId":"44235177","teamCityBuildHeadRef":"6c1887424f1fbc70553c27c3b003df36afcc3a07","teamCityBuildStatus":"PENDING","replyApproveReviewId":null} --> OK, I've already triggered ReadyForMerge build for you.

@bot-gradle test rFM

Looks good, the commit only needed a few cosmetic adjustments

I've updated the upgrade guide.

<!--- The issue this PR addresses --> Fixes #?

Context

<!--- Why do you believe many users will benefit from this change? --> <!--- Link to relevant issues or forum discussions here -->

Contributor Checklist

• [ ] Review Contribution Guidelines
• [ ] Make sure that all commits are signed off to indicate that you agree to the terms of Developer Certificate of Origin.
• [ ] Make sure all contributed code can be distributed under the terms of the Apache License 2.0, e.g. the code was written by yourself or the original code is licensed under a license compatible to Apache License 2.0.
• [ ] Check "Allow edit from maintainers" option in pull request so that additional changes can be pushed by Gradle team
• [ ] Provide integration tests (under <subproject>/src/integTest) to verify changes from a user perspective
• [ ] Provide unit tests (under <subproject>/src/test) to verify logic
• [ ] Update User Guide, DSL Reference, and Javadoc for public-facing changes
• [ ] Ensure that tests pass sanity check: ./gradlew sanityCheck
• [ ] Ensure that tests pass locally: ./gradlew <changed-subproject>:quickTest

Gradle Core Team Checklist

• [ ] Verify design and implementation
• [ ] Verify test coverage and CI build status
• [ ] Verify documentation
• [ ] Recognize contributor in release notes

<!--- Please follow the instructions below. We receive dozens of issues every week, so to stay productive, we will close issues that don't provide enough information.

Please open Android-related issues on the Android Issue Tracker at https://source.android.com/source/report-bugs Please open Gradle Native-related issues at https://github.com/gradle/gradle-native/issues -->

<!--- Provide a brief summary of the issue in the title above -->

Expected Behavior

<!--- Tell us what should happen --> task "test" should run on demand

Current Behavior

<!--- Tell us what happens instead of the expected behavior --> task "test" is triggered by any task, even add -x test

Steps to Reproduce

1. git clone --depth 1 https://github.com/spring-projects/spring-boot.git && cd spring-boot
2. gradle tasks gradle tasks -x test gradle clean will tirgger > Task :buildSrc:test, but ./gradlew(6.9) works as expected.

Your Environment

------------------------------------------------------------
Gradle 7.1
------------------------------------------------------------

Build time:   2021-06-14 14:47:26 UTC
Revision:     989ccc9952b140ee6ab88870e8a12f1b2998369e

Kotlin:       1.4.31
Groovy:       3.0.7
Ant:          Apache Ant(TM) version 1.10.9 compiled on September 27 2020
JVM:          1.8.0_271 (Oracle Corporation 25.271-b09)
OS:           Mac OS X 10.16 x86_64

When you have a buildSrc directory, Gradle always runs the "build" task from buildSrc before evaluating any build scripts in the root build. There hasn't been any change in that area between 6.x and 7.x.

Here's running gradle tasks in 6.9, which runs 104 tests: https://scans.gradle.com/s/rcbrgocjkamf6/tests

Here's running gradle tasks in 7.1, which also runs 104 tests. I assume the failures are related to the upgrade: https://scans.gradle.com/s/5eyixjgna4kd2/tests

I suspect you don't normally see tests running in 6.9 because they're up-to-date or from the build cache.

Could you please add the stack trace you're seeing to the report?

<!--- Please use our bug report template to report problems with something that has never worked.
Regressions reports are greatly appreciated during our RC phase and before a final release. -->

<!--- Provide a brief summary of the issue in the title above --> org.gradle.testkit.runner throwing compilation issue when upgrading to gradle 6.8.1 from 4.10.1.

Expected Behavior

org.gradle.testkit.runner should not throw any compilation issue when upgrade to gradle 6.8.1.

Current Behavior

org.gradle.testkit.runner throwing compilation issue when upgrade to gradle 6.8.1.

Context

Compilation is failling in my workspace.Not able to build the project.

Steps to Reproduce

gradleVersion = '6.8.1' complie 'org.codehaus.groovy:groovy-all:2.5.12'

testCompile 'junit:junit:4.12' testCompile 'org.spockframework:spock-core:1.3-groovy-2.5'

Try running test with testKit. Its not able to find any testKit imports.

Your Environment

<!--- Include as many relevant details about the environment you experienced the bug in --> <!--- A build scan https://scans.gradle.com/get-started is ideal --> Build scan URL:

I can't really help you much without a reproducer. Upgrading two major versions ahead at once always risks breaking something. A couple of things that may help you:

• Add testImplementation gradleTestKit() to the dependencies blocks of the projects that use testkit
• Check upgrade guides and adjust your build files accordingly:
  • From 4 to 5
  • From 5 to 6

classpath = files("$installDist.destinationDir/lib/*")

This isn't doing what it looks like it's doing. That's not creating a wildcard classpath. The classpath is a single file named * in D:\Sourcecode\EMPIC\EAP\EmpicSuite\v-nox\build\install\v-nox\lib\. That's why the error message is about not being able to find a file named *.

I think something like this would be ~equivalent:

classpath = fileTree(dir: "$installDist.destinationDir/lib/", include: "*.jar"))

But this expands into the full list of jars in the directory.

We definitely don't want to support the wildcard in something like files() and I don't think we would add something special to JavaExec/javaexec to allow you to use wildcards in classpaths. Most/all of the time, we want Gradle to know/decide what the classpath order is for up-to-date checks.

Was this working before we added the executable jar special handling?

OK, I've already triggered a build for you.

@bot-gradle test and merge