Blisk 歷史版本列表
更新時間：2023-05-28
更新細節：
What's new in this version:
- Blisk 20.0: New Android mobiles and desktops (including iMac 4k and 5k), and platform update (latest technologies and security improvements)
New devices in Blisk:
- Samsung Galaxy S22, Samsung Galaxy S22 Plus, Samsung Galaxy S22 Ultra, Desktop 4k 1x scale, iMac Pro Retina 5K 27″, iMac Retina 4․5K 24″, iMac Retina 4K 21․5″, iMac Retina 2016 27″ are ready to use in the Blisk app, where you can run a mobile test, a responsive test, or a cross-device test. These devices are preinstalled in the Blisk app, so you don't need to download or install anything other than the Blisk app. The new devices run directly on your PC, Mac, or Linux, and the code runs locally, avoiding potential data loss or security issues.
- Requirements: this feature is available in Blisk v.20.0.176.140 and later. You may need to update the Blisk application to use this feature. View Documentation.
- Starting with v.20.0.176.140, Blisk opens new possibilities for running different kinds of mobile tests on Samsung Galaxy S22, Samsung Galaxy S22 Plus, Samsung Galaxy S22 Ultra, Desktop 4k 1x scale, iMac Pro Retina 5K 27″, iMac Retina 4․5K 24″, iMac Retina 4K 21․5″, iMac Retina 2016 27″: responsive test, multi-device test, touch events test, performance test, landscape orientation test, dark mode test, test for page errors, slow Internet connection test, etc.
Galaxy S22-series and new desktops: Screen size, Viewport, Pixel Ratio, CSS Media Query, and specification:
The specifications, viewport size, screen size, pixels per inch (PPI), and CSS Pixel Ratio for new devices are available on the Device portal, where you can find the device metrics for all devices including the latest Galaxy S22-series and desktops:
- Samsung Galaxy S22 viewport, resolution, and specs
- Samsung Galaxy S22 Plus viewport, resolution, and specs
- Samsung Galaxy S22 Ultra viewport, resolution, and specs
- Desktop 4K 1X Scale viewport, resolution, and specs
- iMac Pro Retina 5K 27″ viewport, resolution, and specs
- iMac Retina 4․5K 24″ viewport, resolution, and specs
- iMac Retina 4K 21․5″ viewport, resolution, and specs
更新時間：2023-04-23
更新細節：
What's new in this version:
Fixed:
- MethodTooLargeException when instrumenting a class with thousand of lambdas for configuration cache
- Kotlin DSL precompiled script plugins built with Gradle 8.1 cannot be used with other versions of Gradle
- Gradle 8.1 configure freeCompilerArgs for Kotlin in buildSrc breaks build with unhelpful errors
更新時間：2023-04-13
更新細節：
What's new in this version:
New features, performance and usability improvements:
Configuration cache improvements:
- The configuration cache improves build time by caching the result of the configuration phase and reusing it for subsequent builds. This feature, now promoted to stable status, can significantly improve build performance.
Securing the configuration cache:
- To mitigate the risk of accidental exposure of sensitive data, Gradle now encrypts the configuration cache. Gradle will transparently generate a machine-specific secret key as required, cache it under the Gradle user home directory and use it to encrypt the data in the project specific caches.
- By default, the Gradle configuration cache is located under .gradle/configuration-cache in your project directory.
- Every cache entry contains information about the set of tasks to run, along with their configuration and dependency information.
- However, based on a task's implementation or the way it is configured by a plugin or build script, its configuration might contain sensitive information. It is crucial to keep this information secure.
To enhance security further, make sure to:
- prevent the .gradle/configuration-cache folder from being committed to source control or exposed in CI environments;
- secure the Gradle user home directory.
Dependency verification support:
- The configuration cache now fully supports dependency verification. Changes to associated files (keyring files or verification-metadata.xml) are correctly detected and invalidate the configuration cache if necessary.
File system-based repositories support:
- The configuration cache now fully supports file-system-based Ivy and Maven repositories. In particular, this release adds support for dynamic dependencies. Suppose a dynamic dependency is declared in the build script. In that case, changes to the dependency in the file-system-based repository now invalidate the configuration cache to pick up an updated version.
Expanded compatibility with core plugins:
- The Ivy publishing plugin and the Signing plugin are now compatible with the configuration cache.
- The current status of the configuration cache support for all core Gradle plugins can be found in the configuration cache documentation.
Support of Java lambdas:
Gradle can now restore user-provided lambdas from the configuration cache. Using anonymous classes to implement Single Abstract Method (SAM) interfaces is no longer necessary. This also applies to Kotlin code: there is no more need to configure the Kotlin compiler to generate classes instead of lambdas during SAM conversion.
- This release also improves error reporting for lambdas that capture unsupported types, like Configuration.
Better error reporting for Groovy closures:
- This release improves error reporting of unsupported method calls in Groovy closures. For example, a doFirst/doLast action uses a method or property of the Project, which is unsupported with the configuration cache
Previously, a confusing message of Could not get unknown property 'buildDir' for task ':echo' was displayed, but now the error is more accurate
Configuration inputs detection improvements:
The configuration cache needs to detect when the build logic accesses the "outside world" at configuration time (for example, reading files or environment variables) to invalidate the cache if accessed information changes. Every recent Gradle release added new detection capabilities, and this release is no exception. Gradle now detects:
- FileCollections queried at configuration time.
- Methods of java.io.File class used to check file existence and read directory contents.
- Methods of java.nio.files.File class used to open files for reading and to check file existence.
- Kotlin and Groovy helper methods used to read file contents.
Kotlin DSL improvements:
- Gradle's Kotlin DSL provides an alternative syntax to the Groovy DSL with an enhanced editing experience in supported IDEs — superior content assistance, refactoring documentation, and more.
Experimental simple property assignment in Kotlin DSL scripts:
- As an opt-in feature, it is now possible to use the = operator to assign values to Property types in Kotlin scripts as an alternative to the set() method. This reduces the verbosity of Kotlin DSL when lazy property types are used to configure tasks and extensions. It also makes Kotlin DSL behavior consistent with Groovy DSL behavior, where using = to assign lazy properties has always been available.
- Lazy property assignment for Kotlin scripts is an experimental opt-in feature. It is enabled by adding systemProp.org.gradle.unsafe.kotlin.assignment=true to the gradle.properties file.
Access to version catalog for plugins in the plugins {} block:
- Version catalog accessors for plugin aliases in the plugins {} block aren't shown as errors in IntelliJ IDEA and Android Studio Kotlin script editor anymore. If you were using a workaround for this before, see the corresponding section in the upgrading guide.
Useful deprecation warnings and errors from Kotlin script compilation:
- Gradle Kotlin DSL scripts are compiled by Gradle during the configuration phase of your build.
- Deprecation warnings found by the Kotlin compiler are now reported on the console when compiling build scripts. This makes it easier to spot usages of deprecated members in your build scripts.
- Moreover, Kotlin DSL script compilation errors are now always reported in the order they appear in the file. This makes it easier to figure out the first root cause of a script compilation failure.
Easier access to extensions on the Gradle object:
- The Gradle type now declares that it is ExtensionAware. This allows access to extensions without casting to ExtensionAware from Kotlin. This can be useful in initialization scripts.
Easier configuration of Test.forkEvery from Kotlin:
- It is now easier to configure the forkEvery property of Test tasks from Kotlin to set the maximum number of test classes to execute in a forked test process. Instead of requiring to use its setForkEvery(<number>) setter you can now simply assign it a value
Improvements to development of Gradle plugins in Kotlin:
- The kotlin-dsl plugin provides a convenient way to develop Kotlin-based plugins that contribute build logic.
- In addition to plugins written as standalone projects, Gradle also allows you to provide build logic written in Kotlin as precompiled script plugins. You write these as *.gradle.kts files in src/main/kotlin directory.
Easier customization of Kotlin options:
- Customization of Kotlin options in your build logic is now easier and no longer requires afterEvaluate {}.
- The standalone script compilation for build scripts, init scripts, and applied scripts are configured to skip the pre-release check to allow referencing Kotlin code compiled with more recent Kotlin language versions on a best-effort basis.
The kotlin-dsl plugin is now published to the Gradle Plugin Portal with proper licensing information in its metadata. The plugin is published under the same license as the Gradle Build Tool: the Apache License Version 2.0.
- This makes using the kotlin-dsl plugin easier in an enterprise setting where published licensing information is required.
Respect --offline when building precompiled script plugins:
- Building precompiled script plugins now respects the --offline command line execution option.
- This makes using Gradle plugins that react to --offline from precompiled script plugins easier.
Less verbose compilation with precompiled script plugins:
- Building precompiled script plugins includes applying plugins to synthetic projects. This can produce some console output.
- The output is now captured and only shown in case of failures. By default, this is now less verbose and does not clutter the console output.
Better validation of name and path of precompiled script plugins:
- Precompiled script plugins must respect the documented naming conventions. Gradle will now fail with an explicit and helpful error message when naming conventions are not followed.
- Moreover, .gradle.kts files present in resources src/main/resources are not considered as precompiled script plugins anymore. This makes it easier to ship Gradle Kotlin DSL scripts in plugins resources.
JVM:
Support for building projects with Java 20:
- Gradle now supports using Java 20 for compiling, testing, and starting other Java programs. This can be accomplished by configuring your build or task to use a Java 20 toolchain.
- You cannot currently run Gradle on Java 20 because Kotlin lacks support for JDK 20. However, you can expect support for running Gradle with Java 20 in a future version.
Faster Codenarc analysis with parallel execution by default:
- The Codenarc plugin performs quality checks on your project’s Groovy source files using a static code analyzer. It now uses the Gradle worker API and JVM toolchains.
- CodeNarc now performs analysis via an external worker process which allows it to run in parallel within a single project.
- In Groovy projects, this tool will use the same version of Java the project requires. In other types of projects, it will use the same version of Java used by the Gradle daemon.
Other Improvements:
Gradle Wrapper introduces labels for selecting the version:
- The --gradle-version parameter for the wrapper task now supports using predefined labels to select a version.
The recognized labels are:
- latest selects the latest stable version
- release-candidate selects the latest release candidate version
- nightly selects the latest unstable nightly version
- release-nightly selects the latest unstable nightly version for the next release
- More details can be found in the Gradle Wrapper section.
Build Init plugin incubating flag enables more incubating features:
- When generating a new project with the init task with the --incubating option, parallel project execution and task output caching will be enabled for the generated project by creating a gradle.properties file and setting the appropriate flags in it.
Better memory management:
- To better manage memory usage, Gradle proactively stops unused worker processes before starting new ones.
- Gradle first checks if the available physical memory can accommodate the maximum heap requirements of a new worker process. If not, it searches for unused worker processes that can be stopped to free up enough physical memory for the new process.
- Previously, Gradle sought to acquire enough memory to satisfy the minimum heap requirements of the new process. However, in cases where the minimum heap and maximum heap of the worker process are very different, the memory freed up before the process starts may not be close to sufficient for the eventual size of the process.
- Gradle now attempts to acquire enough memory to satisfy the new process's maximum heap requirements.
- This causes the physical memory management to be more aggressive when starting up new processes, and in many cases, will result in better overall memory usage.
Easier consumption of Shared Build Services:
- There is a new @ServiceReference annotation that makes it easier to consume shared build services.
- By annotating a property with @ServiceReference, you no longer need to remember to explicitly declare that your task uses a shared build service via Task#usesService().
- If you also provide the name of the service in the annotation, you no longer need to obtain and assign a build service reference to the property explicitly; if a service registration with the given name exists, the corresponding reference is automatically assigned to the property.
- More details in the Shared Build Services documentation on using build services.
New Dataflow Actions replace buildFinished listeners:
- Previously, Gradle had only Gradle.buildFinished listeners to handle the result of the build. For many reasons, this API doesn't work well with the configuration cache, but there were no proper replacements. With the new Dataflow Actions you can now schedule pieces of work to process the result of the build in a way that is configuration-cache compatible. For example, you can add code to play a sound when the build completes successfully
- Unlike callbacks, actions provide the necessary level of isolation to ensure safe configuration caching.
- In this release, dataflow actions only provide a replacement for the deprecated Gradle.buildFinished callback, but more options to add work outside the task graph are planned.
Gradle user home caches are ignored by backup tools that honor CACHEDIR.TAG:
- Caches in the Gradle user home can become very large and typically do not contain files that need to be searched or backed up. The CACHEDIR.TAG specification proposes a way for archive and backup tools to automatically skip these directories, which makes it unnecessary to explicitly exclude them. Gradle now marks directories that should be ignored with a CACHEDIR.TAG file.
IDE Integration:
- The following improvements are for IDE integrators. They will be available for end-users in future IDE releases once they are used by IDE vendors.
- Builds launched via the IDE use the same log level as the command-line
- Previously, when executing a build via the IDE, the log level settings provided in the project's gradle.properties file were ignored. Some IDE vendors worked around this shortcoming by setting the log level in other ways to meet user expectations.
- The Tooling API now honors the org.gradle.logging.loglevel setting in the project's gradle.properties and applies it as expected to builds started from the IDE.
Promoted features:
- Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility.
- See the user manual section on the “Feature Lifecycle” for more information.
- The following are the features that have been promoted in this Gradle release.
Configuration cache:
- The configuration cache feature is now officially out of incubation and is ready for general use. It is important to note, however, that utilizing this feature may require modifications to build logic and applied plugins to ensure full support.
- The implementation of the configuration cache is not yet complete. However, you can expect the configuration cache to evolve with new features and enhancements in upcoming Gradle versions, offering support for a broader range of use cases. To explore the features currently under consideration for implementation, please refer to the documentation.
- Enabling the configuration cache can yield a significant boost in build performance, as it caches the result of the configuration phase and reuses it for subsequent builds. This means that subsequent builds no longer have to re-execute the configuration phase, resulting in faster and more efficient builds.
- Configuration cache was introduced as an experimental feature back in Gradle 6.6.
- To learn how to benefit from this feature, refer to the Configuration Cache documentation.
Promoted features in the Provider API:
The ValueSource API is no longer incubating. The following classes and methods are now considered stable:
- ProviderFactory.of(Class, Action)
- ValueSource
- ValueSourceParameters
- ValueSourceParameters.None
- ValueSourceSpec
Fixed:
- 133 issues have been fixed in Gradle 8.1
- Artifact transforms should be allowed to run external processes
- Upgrading to gradle 8.0.2 causes deadlock
- Narrowing of return type in internal DepedencyResolutionServices breaks IDE tests
- Gradle 8 reports incorrect Configuration flags despite being configured correctly
- The `useJUnitPlatform` setting in `KotlinDSL` does not work correctly since Gradle 8.0
- Gradle throws/catches a lot of exceptions in AttributeMatchingVariantSelector
- `--scan` is ignored if configuration cache is reused
- Exception thrown from ValueSource should be a configuration cache problem
- JUnit 4.13 jar from gradle distribution should not leak into test runtime classpath
- precompiled script plugin "is not supposed to be used along with regular Kotlin sources" in Gradle 8.1
- The `kotlin-dsl` plugin using `afterEvaluate {}` to configure `KotlinCompile` tasks prevents further configuring them
- Exclude rule merging: missing optimization
- Reduce `OutputEventRenderer.onOutput()` locking by refine lock granularity
- Configuration cache failure when tasks are excluded by path
- Deprecate Test task default classpath and testClassesDirs
- Anchor around example captions in the docs includes formatting tags verbatim
- Remove testng from Maven migration integration test
- buildSrc precompiled script plugin named `init.gradle.kts` causes obscure error: Failed to apply plugin class, Char sequence is empty
- Gradle generates broken links in logs
- gradle :help produces wrong output on warm configuration cache
- Make help tasks plugin work with configuration cache/load-after-store
- Make `dependencyInsight` work with CC/load-after-store
- Make :dependentComponents work with Configuration Cache
- Refactor the configuration cache instrumentation/interception machinery
- Dependency verification documentation snippets should reference XSD
- Potentially bad assertion in ClasspathUtil
- Java toolchain auto-detection on linux should look in /usr/local/java
- Building Java Modules with Blackbox Tests Sample new sample returns 404
- Since Gradle 7.6 my integration tests fail - but report "BUILD SUCCESSFUL"
- --offline is not respected for "synthetic root projects"
- Fix Toolchain related test failures on M1 Macs
- Consider supporting assignment overload for ConfigurableFileCollection
- Reintroduce worker api for CodeNarc
- Deprecate org.gradle.cache.cleanup property
- Dependency graph resolution: Equivalent excludes can cause un-necessary graph mutations
- Add documentation for Kotlin DSL assignment overloads
- Dogfood Kotlin DSL assignment overload
- Configure implicit receiver for `KotlinBuildScript`, `KotlinInitScript` and `KotlinSettingsScript`
- Intermittent: "You must specify a base url or at least one artifact pattern for an Ivy repository" even when a base url is specified
- Deprecate running Gradle workers on Java runtimes below 8
- Support compiling and testing with Java 20
- Document and promote use of ServiceReferences
- When configuration cache is enabled report usages of `Gradle.useLogger()`
- Investigate project.layout.buildDirectory property resolution errors on a warm cache
- Signing plugin does not sign Gradle module metadata artifact for Ivy publication
- Should avoid publishing an artifact if the task that created it was skipped
- Use testSourceSets.add(sourceSets.functionalTest) instead of testSourceSets(sourceSets.functionalTest)
- Enable agent-based instrumentation by default
- Regression: Running codenarc against Groovy4 projects is broken
- VersionConstraint.branch and ModuleDependency.endorsing are not copied when a dependency is copied.
- Update documentation for configuration cache improvements in Gradle 8.1
- Stricter validation in BuildServicesRegistry.registerIfAbsent fails in cases it worked before
- Remove/replace retired lgtm
- The `Gradle` type does not expose that it is `ExtensionAware` making accessing extensions and extra properties difficult in the Kotlin DSL
- Add nagging for using `JvmVendorSpec.IBM_SEMERU`
- Missing 'archiveName' attribute in eclipse wtp
- `ValidatePlugins` task fails if configured Java Toolchain > Java running the build
- Version catalogs: library names cannot end with `-class`
- Allow configuration of Eclipse build directory
- change title of upgrade doc for "7.x to latest" to "7.x to 8.0"
- Sporadic NPEs when compiling Java code
- Shared Build Services consumed using @ServiceReference are instantiated even if not used
- DefaultWorkerProcessBuilder asking for too little memory
- Inconsistency between javadocElements and javadoc variants
- Support instrumenting signed build logic JARs
- Gradle complains about invalid tool chain - picking up the source package location - it should just ignore them
- Nag for deprecation of StartParameter.buildFile/settingsFile
- Nag for deprecation of GradleBuild.buildFile
- Version catalog accessors for plugin aliases shown as errors in IDE kotlin script editor
- Fix dependency reporting tasks to be compatible with configuration caching
- Java projects generated with `gradle init` should use toolchains
- Allow directory listing to be an input to config cache.
- Add API to configure SourceSetOutput classesDirs
- Lock Configuration Usage at Creation
- Configuration cache should report a problem when a task extension is accessed at execution time
- publishToMavenLocal does not generate checksums
- Disallow BuildServices to be used as inputs to ValueSources obtained at configuration time
- Kotlin-dsl plugin modifies kotlinOptions.freeCompilerArgs in task action
- Log deprecation for applying Kotlin precompiled script plugins published with Gradle < 6.0
- Load tasks from the configuration cache in the same build they are stored
- includeGroupByRegex with exclusiveContent can be easily misconfigured leading to poor security
- Add deprecation logging to org.gradle.util.ConfigureUtil.configureByMap(props,delegate)
- Add deprecation logging to org.gradle.util.VersionNumber
- Add deprecation logging to org.gradle.util.GUtil.toCamelCase(string)
- Add deprecation logging to org.gradle.util.WrapUtil.toDomainObjectSet()
- gradlew init should set parallel and caching to true
- Configuration cache should report Task.getProject access inside Task.onlyIf, TaskOutputs.cacheIf, and TasksOutputs.upToDateWhen predicates
- Validate unknown implementation snapshots earlier
- application.defaultJvmArgs aren't applied when running from the configuration cache
- [KTS] Pre-release classes were found in dependencies. Remove them from the classpath, recompile with a release compiler or use '-Xskip-prerelease-check' to suppress errors
- Share more information (licensing, repo url) about the Kotlin DSL Plugin both on the Plugin Page and in the published Maven POM
- Support SARIF format in Checkstyle plugin
- In tooling API FileDownloadResult is successful for HTTP 404
- "Error while evaluating property 'javaVersion' of task ':compileJava' > No value present" when using relative javac path
- Provider gets evaluated twice with configuration cache enabled
- Avoid degraded performance for missing task dependency detection
- Laziness issue between historical metadata and GMM metadata for publishing
- Provide explicit path on parse error from toml Version Catalog file
- Mark global cache directories
- Build finished event now deprecated
- Configuration cache should report problems when dehydrating `Closure`s
- Gradle doesn't recognize disabled parameterized junit5 tests
- Promote configuration caching as a stable feature
- `ISE: GradleProperties has not been loaded yet` for included build when restoring from the configuration cache
- Make dependency verification compatible with configuration cache
- Improve naming in DirectorySnapshotter for filtered snapshots
- Build launched via TAPI ignores logger level settings of target build
- Configuration cache doesn't load system properties from included build `gradle.properties` files
- Gradle configuration cache failure when using Gradle Enterprise
- Adding a formerly-missing `build.gradle` to a multi-project build with configuration-cache doesn't get picked up
- Path sensitivity `NONE` in incremental task causes same file to be added then removed
- Build fails when kotlin-dsl plugin is used and src/main/resources/init.gradle.kts file exists
- Introduce a mechanism to obtain the build result when using configuration caching
- Make Gradle's memory management work appropriately in memory constrained docker containers
- Test.forkEvery property awkward to use from Kotlin because of getter/setter nullability mismatch
- Automatically register a build service user when it is wired to a managed property
- Simplify consumption of Shared Build Services
- Builds fail if root project is in root of mount point, with further implications
- Promote incubating `org.gradle.api.provider.ValueSource` and family
- Enable the "Gradle User Manual" page show the vertical menu located in the left for a mobile device
- Configuration cache should support dynamic dependencies with ivy file system repositories
- Restore default excludes from the configuration cache
- Configuration cache should support file-system based repositories
- Possibility to automatically use "latest" Gradle version for wrapper task
- Make `project-report` plugin support the configuration cache
- Make `signing` plugin support the configuration cache
- Make `ivy-publish` plugin support the configuration cache
- Introduce RegularFileProperty to represent output of WriteProperties task
- Misleading javadoc on org.gradle.api.java.archives.Manifest.from() methods
- Gradle should warn against using COD in combination with Kotlin DSL
- Spurious console output when generating accessors for precompiled Kotlin scripts
- Gradle wrapper can't recover from corrupted download
- JUnit 5 Dynamic tests not showing with their displayName
更新時間：2023-04-13
更新細節：
What's new in this version:
Fixed:
- Platform dependencies not possible in dependency block of test suite plugin
- Increased memory usage (with -p option)
- Building gradle itself fails during toolchain download: permission denied copying a file within .gradle/jdks
- Regression with 7.6: @pom artifact in JVM library project is no longer found
- Remove safe credentials reference
- Kotlin MPP plugin broken with Gradle 7.6 due to signature change in TestResultProcessor
- toolchainManagement.jvm.javaRepositories should not expose the full surface of NamedDomainObjectList
- Back-port toolchain related fixes to 7.6.1
- Auto-provisioning/auto-detection of IBM Semeru toolchains is broken with Gradle 7.6
- Docs: Build Lifecycle starts halfway through a point
- Classifiers of version catalog are discarded while copied to anothor dependency
- Ant closures are broken with Gradle 7.6
- Mention the Foojay Toolchain Resolver plugin in the Gradle manual
- Gradle 7.6: high memory usage (android project)
- Backport to 7.6.1 "Fix for Incremental compilation with modules"
- "Unable to make progress running work" together with --continue and failing tasks (Backport to 7.6.1)
- Improve Toolchain related deprecation nagging in 7.6
- Update EOL policy
- Backport trusting only full GPG keys in dependency verification [Backport 7.6.1]
- Typo in v7.6 docs about disabling_the_daemon
- Resolving of manually created configuration creates a ResolveException
更新時間：2023-04-06
更新細節：
更新時間：2023-03-15
更新細節：
更新時間：2023-03-04
更新細節：
What's new in this version:
Fixed:
- Gradle 8 RC2 runs out of metaspace
- Java/Scala build with no explicit toolchain: build fails with Gradle 8.0.1 / Scala 2.13
- Gradle 8.0.+ silently dropped support for custom compilers in JavaCompile
- InstrumentingTransformer generates different class files in Gradle 8 and 7.6 which leads to Remote Build-Cache misses
- Extending an already resolved configuration no longer works correctly
- Update configuration cache state for some plugins
- includeBuild in PluginManagementSpec deincubated in Gradle 8, docs still say it's incubating
- Document integration of Scala plugin with toolchains and problems with target flag
- --no-rebuild suddenly gone without new deprecation cycle and without the reason for its undeprecation being void
- Gradle 8.0 fails Scala build with isBlank not found in String class error
更新時間：2023-02-18
更新細節：
What's new in this version:
Fixed:
- Document integration of Scala plugin with toolchains and problems with target flag
- --no-rebuild suddenly gone without new deprecation cycle and without the reason for its undeprecation being void
- Gradle 8.0 fails Scala build with isBlank not found in String class error
更新時間：2023-02-15
更新細節：
What's new in this version:
- New features, performance and usability improvements
- Kotlin DSL
- Gradle's Kotlin DSL provides an alternative syntax to the traditional Groovy DSL with an enhanced editing experience in supported IDEs, with superior content assistance, refactoring, documentation, and more.
- Improved script compilation performance
- Gradle 8.0 introduces an interpreter for the declarative plugins {} blocks in .gradle.kts scripts that make the overall build time around 20% faster. Calling the Kotlin compiler for declarative plugins {} blocks is avoided by default.
To utilize this performance, ensure you are using the supported formats in the declarative plugins {} blocks, for example:
- plugins {
- id("java-library") // <1>
- id("com.acme.example") version "1.0" apply false // <2>
- kotlin("jvm") version "1.7.21" // <3>
- Plugin specification by plugin identifier string
- Plugin specification with version and/or the plugin application flag
- Kotlin plugin specification helper
- Note that using version catalog aliases for plugins (e.g. plugins { alias(libs.plugins.acme) }) or plugin specification type-safe accessors (e.g. plugins { `acme-plugin` }) is not supported by the plugins {} block interpreter. This support will be added in a later version.
- In unsupported cases, Gradle falls back to the Kotlin compiler, providing the same performance as previous Gradle releases.
- For more information on plugin syntax, read the documentation on constrained syntax.
- Updated the Kotlin DSL to Kotlin API level 1.8
- Previously, the Kotlin DSL used Kotlin API level 1.4. Starting with Gradle 8.0, the Kotlin DSL uses Kotlin API level 1.8. This change brings all the improvements made to the Kotlin language and standard library since Kotlin 1.4.0.
- For information about breaking and non-breaking changes in this upgrade, visit the upgrading guide.
- Enhanced script compilation to use the Gradle JVM as Kotlin JVM target
- Previously, the compilation of .gradle.kts scripts always used Java 8 as the Kotlin JVM target. Starting with Gradle 8.0, it now uses the version of the JVM running the build.
- If your team is using e.g., Java 11 to run Gradle, this allows you to use Java 11 libraries and language features in your build scripts.
- Note that this doesn't apply to precompiled script plugins, see below.
- Precompiled script plugins now use the configured Java Toolchain
- Previously, the compilation of precompiled script plugins used the JVM target as configured on kotlinDslPluginOptions.jvmTarget.
- Starting with Gradle 8.0, it now uses the configured Java Toolchain, or Java 8 if none is configured.
- See the kotlin-dsl plugin manual for more information on how to configure the Java Toolchain for precompiled script plugins and the migration guide for more information on changed behaviour.
- Improvements for buildSrc builds
- This release includes several improvements for buildSrc builds to behave more like included builds. Included builds are an alternative way to organize your build logic to separate project configurations to better utilize incremental builds and task caching. Now they offer the same benefits.
- Run buildSrc tasks directly
- It is now possible to run the tasks of a buildSrc build from the command-line, using the same syntax used for tasks of included builds. For example, you can use gradle buildSrc:build to run the build task in the buildSrc build.
- For more details, see the user manual
- buildSrc can include other builds
- The buildSrc build can now include other builds by declaring them in buildSrc/settings.gradle.kts or buildSrc/settings.gradle. This allows you to better orgaize your build logic while still using buildSrc.
- You can use pluginsManagement { includeBuild(someDir) } or includeBuild(someDir) in this settings script to include other builds in buildSrc.
- For more details, see the user manual
- Tests for buildSrc are no longer automatically run
- When Gradle builds the output of buildSrc it only runs the tasks that produce that output. It no longer runs the build task. In particular, this means that the tests of buildSrc and its subprojects are not built and executed when they are not needed.
- You can run the tests for buildSrc in the same way as other projects, as described above.
- Init scripts are applied to buildSrc
- Init scripts specified on the command-line using --init-script are now applied to buildSrc, in addition to the main build and all included builds.
- For more details, see the user manual
- Configuration cache
- The configuration cache improves build time by caching the result of the configuration phase and reusing this for subsequent builds. This is an incubating feature that can significantly improve build performance.
- Improved configuration cache for parallelism on the first run
- Configuration cache now enables more fine-grained parallelism than using the parallel execution. Starting in Gradle 8.0, tasks run in parallel from the first build when using the configuration cache.
- Gradle has always run tasks in parallel when it reuses a configuration cache entry. All tasks run in parallel by default, even those within the same project, subject to dependency constraints. Now, it does this also when storing a cache entry.
- When the configuration cache is enabled and Gradle is able to find a compatible cache entry for the current build, it will load the tasks from the cache and run them in isolation. If Gradle cannot find a suitable cache entry, it will run the configuration phase to determine the necessary tasks, store them in a new cache entry, and then immediately run the build based on the saved state.
This new behavior has several benefits:
- Any issues that occur during deserialization will be easier to detect because they will be reported in the cache miss build.
- Tasks have the same state in both cache miss and cache hit builds, allowing for consistency between builds.
- Gradle can release memory used by the configuration state before task execution in the cache miss build, which reduces peak memory usage.
- This consistent behavior between cache miss and cache hit builds will help those who are transitioning to using the configuration cache, as more problems can be discovered on the first (cache miss) build.
- For more details, see the user manual.
- Improved compatibility with core plugins
- The gradle init command can be used with the configuration cache enabled.
- The ANTLR plugin and Groovy DSL precompiled scripts are now compatible with the configuration cache.
- The current status of the configuration cache support for all core Gradle plugins can be found in the configuration cache documentation.
- Java Toolchains improvements
- Updated toolchain download repositories
- Gradle 7.6 introduced toolchain repositories for increased flexibility. In Gradle 8.0, there is no longer a default toolchain provisioner. You have to declare at least one Java Toolchain repository explicitly. This can be done via toolchain repository plugins, like the Foojay Toolchains Plugin:
- plugins {
- id("org.gradle.toolchains.foojay-resolver-convention") version("0.4.0")
- For more details, see the user manual.
- General improvements
- Improved Gradle user home cache cleanup
- Previously, cleanup of the caches in Gradle user home used fixed retention periods (30 days or 7 days, depending on the cache). These retention periods can now be configured via the settings object in an init script in Gradle user home.
- beforeSettings { settings ->
- settings.caches {
- downloadedResources.removeUnusedEntriesAfterDays = 45
- Furthermore, it was previously only possible to partially disable cache cleanup via the org.gradle.cache.cleanup Gradle property in Gradle user home. Disabling cache cleanup now affects more caches under Gradle user home and can also be configured via the settings object in an init script in Gradle user home.
- For more details, see the user manual.
- Enhanced warning modes all and fail are now more verbose
- Before Gradle 8.0, warning modes that were supposed to print all warnings were printing only one for each specific warning message. This resulted in some missing warning messages. For example, if there were two warnings with the same message, but originating from different steps of the build process (i.e., different stack traces), only one was printed.
- Now one gets printed for each combination of message and stack trace. This result is more verbose, but also more complete.
- For more details, see the user manual.
- Improved dependency verification metadata
- Dependency verification metadata helps keep your project secure by ensuring the dependency being used matches the checksum of that dependency. This metadata is located in an XML configuration file and now accepts a reason attribute. This reason attribute allows for more details on why an artifact is trusted or why a selected checksum verification is required for an artifact directly in the verification-metadata.xml.
The following nodes with dependency verification metadata file verification-metadata.xml now support a reason attribute:
- the trust xml node under trusted-artifacts
- the md5, sha1, sha256 and sha512 nodes under component
- A reason is helpful to provide more details on why an artifact is trusted or why a selected checksum verification is required for an artifact directly in the verification-metadata.xml.
- For more details, see the user manual.
Improved dependency verification CLI:
- To minimize the number of times CI builds communicate with key servers, we use a local keyring file. This file should be frequently exported to remain accurate. There is no longer a need to write verification metadata when exporting trusted keys, simplifying the process.
You can now use the export-keys flag to export all already trusted keys:
- ./gradlew --export-keys
- There is no longer a need to write verification metadata when exporting trusted keys.
- For more details, see the user manual.
- Code quality plugin improvements
- CodeNarc plugin detects the Groovy runtime version
- CodeNarc performs static analysis for Groovy projects. It now publishes separate versions for use with Groovy 4. Gradle still currently ships with Groovy 3.
- To ensure future compatibility, the CodeNarc Plugin now automatically detects the appropriate version of CodeNarc for the current Groovy runtime.
- You can still explicitly specify a CodeNarc version with the toolVersion property on the CodeNarcExtension
- Enhanced PMD tasks to execute in parallel by default
- The PMD plugin performs quality checks on your project’s Java source files using a static code analyzer. It now uses the Gradle worker API and JVM toolchains. This tool now performs analysis via an external worker process, and therefore its tasks may now run in parallel within one project.
- In Java projects, this tool will use the same version of Java required by the project. In other types of projects, it will use the same version of Java that is used by the Gradle daemon.
- For more details, see the user manual
Promoted features:
- Promoted features are features that were incubating in previous versions of Gradle but are now supported and subject to backwards compatibility. See the User Manual section on the “Feature Lifecycle” for more information.
- The following are the features that have been promoted in this Gradle release
Promoted features in the Tooling API:
- The GradleConnector.disconnect() method is now considered stable
- Promoted features in the antlr plugin
- The AntlrSourceDirectorySet interface is now considered stable
- Promoted features in the ear plugin
- The Ear.getAppDirectory() method is now considered stable
- Promoted features in the eclipse plugin
- The EclipseClasspath.getContainsTestFixtures() method is now considered stable
- Promoted features in the groovy plugin
The following type and method are now considered stable:
- GroovySourceDirectorySet
- GroovyCompileOptions.getDisabledGlobalASTTransformations()
- Promoted features in the scala plugin
- The ScalaSourceDirectorySet interface is now considered stable
- Promoted features in the war plugin
- The War.getWebAppDirectory() method is now considered stable
- Promoted features in the Settings API
- The methods Settings.dependencyResolutionManagement(Action) and Settings.getDependencyResolutionManagement() are now considered stable
- All the methods in DependencyResolutionManagement are now stable, except the ones for central repository declaration
Fixed:
- 208 issues have been fixed in Gradle 8.0
- CVE-2022-36033: Bump version for "jsoup" plugin
- "Unable to make progress running work" together with --continue and failing tasks
- ZipFileTree Cache not respecting relocated build directory
- compileScala throws java.lang.UnsupportedOperationException since 8.0-milestone-5
- Caused by: java.lang.ClassCastException: class com.android.build.gradle.internal.plugins.AppPlugin$ApplicationAndroidComponentsExtensionImplCompat_Decorated cannot be cast to class kotlin.Unit
- Don't store broken values to the configuration cache
- Do not discard build services that are build event listeners after storing the configuration cache entry
- CVE-2022-31159: Bump version for the "aws-java-sdk-s3" plugin
- Make a decision wrt staying on Kotlin 1.7 with language 1.5 or moving to Kotlin 1.8 with language 1.8 for 8.0
- Build services closed twice with configuration cache in 8.0
- Failure while populating the build operation queue: Value for unknown value has not been calculated yet.
- Incremental compilation of java modules is broken with Gradle 7.6
- Easier debugging of CompileTransaction path selection in incremental task execution
- Change deprecation of custom layout to be removed in 9.0 instead of 8.0
- Incremental compilation is not observed for Scala 3
- Show usage information (e.g. description) when @Option is specified incorrectly on command line
- Variant ambiguity introduced by compileElements in Gradle 8.0-milestone4
- IDE import fails with Project Isolation enabled: Expected unreportedProblemInCurrentCall to be called after enterDynamicCall
- HashMap$Node cannot be cast to class java.util.HashMap$TreeNode
- JacocoReportAggregationPlugin doesn't work with lockfiles
- Task dependencies access becomes an error in 8.0 with STABLE_CONFIGURATION_CACHE
- Upgrade embedded Kotlin to 1.7.21
- Assertion failed in FinalizerGroup with Kotlin 1.7.21
- Use absolute path to java agent jar when launching JaCoCo process
- Dead Javadoc links in Gradle user guide
- Remove deprecated PluginDependenciesSpecExtensions build-scan method
- Explain need for deprecated DependencyHandlerScope constraints method
- Java Toolchain auto-provisioning fails with permission errors
- Docs: USER_HOME vs GRADLE_USER_HOME vs HOME?
- Aggregration plugins not working with custom JVM Test Suites
- Gradle 8.0-milestone-3 regression: Transform selection algorithm has changed (longer chain is selected)
- Typo and ordering problem for org.gradle.welcome property in docs
- forkOptions.jvmArgs.addAll() silently ignored
- API: parameter is marked not-null while explicitly allowing null
- Kotlin/Groovy Switch in Documentation
- Add a sample demonstrating build service receiving task execution events
- Groovy and Java joint compilation failure on Java class private dependency change
- Inconsistent Javadoc in `ModuleVersionIdentifier`
- Remove various deprecated fields from Usage class
- Misleading toolchain logging when setting executable or java home on compileJava
- Task compileJava fails if fork options executable or java home points to older JDK
- Remove deprecated PluginCollection add/remove/addAll/removeAll/clear methods
- Remove deprecated ResolvedComponentResult#getVariant method
- Signing publications should be idempotent
- Gradle not honoring Maven exclusions defined in pom.xml
- Remove deprecated getAntBuilder from Checkstyle/Pmd/CodeNarc
- Update WarPlugin and ScalaBasePlugin configureConfigurations to produce error instead of warning on misuse
- Add dependency verification changes to release notes for Gradle 8
- Publish dependency-verification-1.2.xsd schema
- Restore removed IdeaModule.testSourceDirs and IdeaModule.testResourceDir
- NoClassDefFoundError: LauncherSessionListener with plugin 'org.jetbrains.intellij' and JUnit 5
- Preset Binary Compatibility Report Filter
- Make binary compatibility changes report self-correcting
- Add task to sort accepted-public-api-changes.json file
- Restore `TestReport`'s removed `reportOn` and `setDestinationDir` methods
- Report#getOutputLocation() should return a Property, not a Provider
- Error upon consuming confs added JacocoPlugin#addJacocoConfigurations
- Add nagging upon usage of deprecated destinationDir from AbstractCompile
- Upgrade embedded Kotlin to 1.7.22
- Restore warning for resolveToStateOrLater
- Build Cache documentation link to Gradle Enterprise is broken
- Centralize validation of executable configuration for tasks
- Prepare to make more usage of `DeprecatableConfiguration` into errors
- Remove DefaultConfiguration#resolveToStateOrLater
- Investigate how to apply DependencyAdder pattern to "modifiers"
- Remove deprecated KotlinDslOptions.experimentalWarning
- Remove @Deprecated AbstractExternalModuleDependency#setForce method
- Update DefaultRepositoryHandler#deprecateJCenter deprecation to Gradle 9.0
- Remove @Deprecated DependencyNotationParser#create method
- ProviderFactory: provide a way to get Gradle properties by a prefix
- `JavaToolchainFactory#newInstance` silently discards original exception
- Signing plugin: sign(publications) should be idempotent
- CCH22-28: Adjust the `snippets/tutorial/configureTaskUsingProjectProperty` sample for configuration cache
- CCH22-27: Adjust the `snippets/testing/test-suite-multi-configure-each-matching` sample for configuration cache
- CCH22-26: Adjust the `snippets/testing/test-suite-multi-configure-each` sample for configuration cache
- CCH22-25: Adjust the `snippets/testing/test-suite-multi-configure-each-extracted` sample for configuration cache
- CCH22-24: Adjust the `snippets/tasks/incrementalTask` sample for configuration cache
- CCH22-23: Adjust the `snippets/tasks/incrementalBuild-customTaskClass` sample for configuration cache
- CCH22-22: Adjust the `snippets/providers/propertyConvention` sample for configuration cache
- CCH22-21: Adjust the `snippets/kotlinDsl/multiProjectBuild` sample for configuration cache
- CCH22-20: Adjust the `snippets/java/fixtures` sample for configuration cache
- CCH22-19: Adjust the `snippets/java/customDirs` sample for configuration cache
- CCH22-18: Adjust the `snippets/java/crossCompilation` sample for configuration cache
- CCH22-17: Adjust the `snippets/files/fileCollections` sample for configuration cache
- CCH22-16: Adjust the `snippets/files/archivesChangedBaseName` sample for configuration cache
- CCH22-15: Adjust the `snippets/files/archiveNaming` sample for configuration cache
- CCH22-14: Adjust the `snippets/dependencyManagement/managingTransitiveDependencies-excludeForDependency` sample for configuration cache
- CCH22-13: Adjust the `snippets/dependencyManagement/managingTransitiveDependencies-excludeForConfiguration` sample for configuration cache
- CCH22-12: Adjust the `snippets/dependencyManagement/dependencyVerification-disablingVerification` sample for configuration cache
- CCH22-11: Adjust the `snippets/dependencyManagement/definingUsingConfigurations-custom` sample for configuration cache
- CCH22-10: Adjust the `snippets/dependencyManagement/customizingResolution-metadataRule` sample for configuration cache
- CCH22-9: Adjust the `snippets/dependencyManagement/customizingResolution-ivyMetadataRule` sample for configuration cache
- CCH22-8: Adjust the `snippets/dependencyManagement/customizingResolution-conditionalSubstitutionRule` sample for configuration cache
- CCH22-7: Adjust the `snippets/dependencyManagement/customizingResolution-classifierSubstitutionRule` sample for configuration cache
- CCH22-6: Adjust the `snippets/dependencyManagement/customizingResolution-capabilitySubstitutionRule` sample for configuration cache
- CCH22-5: Adjust the `snippets/buildlifecycle/projectEvaluateEvents` sample for configuration cache
- CCH22-4: Adjust the `snippets/buildCache/cacheable-bundle-task` sample for configuration cache
- CCH22-3: Adjust the `snippets/buildCache/cacheable-bundle` sample for configuration cache
- CCH22-2: Adjust the `snippets/artifacts/generatedFileDependencies` sample for configuration cache
- Turn invalid toolchain spec deprecation into error
- De-incubate or remove ExternalPluginValidationPlugin
- Remove deprecated AntlrSourceVirtualDirectory & AntlrSourceVirtualDirectoryImpl
- Remove deprecated NamedDomainObjectContainerExtension.invoke
- Remove deprecated members of the internal PrecompiledScriptPluginsSupport
- Update dependency-management deprecation warnings to errors in Gradle 8
- Update AbstractCodeQualityPlugin.createConfigurations to become an error in Gradle 8
- Update Test.useTestFramework to throw error upon improper usage
- AntlrPlugin.apply to become an error
- Remove @Deprecated DefaultWorkerExecutor methods
- Remove @Deprecated DefaultDependencyHandler.doAdd(Conf, Obj, Closure)
- Snippet "snippet-init-scripts-configuration-injection" and "snippet-init-scripts-plugins" are not compatible with the configuration cache
- Snippet "snippet-java-toolchain-filters" is not compatible with the configuration cache
- Snippet "snippet-groovy-compilation-avoidance" is not compatible with the configuration cache
- Off-by-one error on Windows path length checks
- Docs: "Building Java Applications Sample" explanation of build.gradle incomplete
- Remove @Deprecated VersionCatalog methods
- Remove @Deprecated methods from TestReport
- Remove @Deprecated JvmPluginsHelper.configureDocumentationVariantWithArtifact method
- Configuration cache report misses implicit usages of project methods, resulting to a crash when reusing the cache
- Remove @Deprecated methods from DependencySubstitutions
- Remove @Deprecated Groovydoc.IncludePrivate
- Remove @Deprecated DependencyInsightReportTask.setLegacyShowSinglePathToDependency
- Remove @Deprecated JacocoPluginExtension.ReportsDir
- Convert work validation warnings from 7.x into errors
- Remove @Deprecated methods from DefaultDomainObjectSet, DefaultSourceDirectorySetFactory and SourceDirectorySetFactory
- Sample "credentials-handling/publishing-credentials" is not compatible with the configuration cache
- Snippet "snippet-maven-publish-conditional-publishing" is not compatible with the configuration cache
- Update docs for adhoc-task property builder runtime API to describe equivalent for all annotations
- `-U` short-form for `--refresh-dependencies`
- Wrong documentation URL in error message
- Remove @Deprecated JacocoMerge for Gradle 8.0
- Add Upgrade Guide notes on Deprecations/Removals
- Default to latest version of CodeNarc tool
- Migrate `groovy.util.AntBuilder` → `groovy.ant.AntBuilder`
- Don't clear `distributionSha256Sum` when updating Gradle wrapper
- Remove Upload task
- Make tasks emit Java toolchain usage when uses the current JVM
- Re-enable disabled test GradleBuildSanityCheckConfigurationCacheSmokeTest
- Cpp and Swift plugin classes use `Optional.orElse` inefficiently
- SystemRoot environment variable needs to be defined for GradleRunner Tests on Windows
- typo in Working with files doc in the user guide
- Unix start script is overwriting the `APP_NAME` env var value
- Configuration cache should support non-serializable lambdas
- Do not track implementation of nested input
- Do not fix JVM target to 8 when compiling build.gradle.kts files
- Remove --add-opens for all Gradle worker processes
- Make `org.gradle.kotlin.dsl.precompiled.accessors.strict` default to true
- Add reason attribute for <component> elements in verification-metadata.xml
- `gradle init` is skipped after generating one project with the configuration cache enabled
- Scala Incremental Compilation for Multi-Module projects broken in 7.x
- Version catalogs run into unexpected namespace conflicts
- Ambiguous error when configuration cache entries discarded due to incompatible types
- A flag to turn `buildSrc` into a composite build
- Move @Internal for getExtensions from ExtensionAware to Task interface
- Support Kotlin language/api 1.7 in Kotlin DSL build scripts and plugins
- Make Task.getName() final
- Error extracting downloaded toolchain for `JvmImplementation.J9`
- Restore Test Option Fail Fast Behavior for Gradle 8
- Missing upgrade docs from 6.9 to 7.0
- DependencyHandler#add(String, Object, Closure) has incorrect nullability
- "The Gradle Daemon" documentation FAQ duplicates content
- Java Toolchains are Incompatible with `--add-exports` for System Modules
- ./gradlew --export-keys does not do anything without --write-verification-metadata
- eclipse-wtp EJB projects are not compatible with eclipse "jst.ejb" facet
- Remove support for using equals() to determine whether a task input property has changed
- Remove deprecated getters/setters that have a stable property as replacement since 7.0
- Kotlin 1.5 ".kts" build source, invoke-dynamic for SAM wrappers, and gradle tasks not up to date
- Repo libs-releases-local outdated, not containing artifacts after 6.1.1
- Enable deprecation logging for deprecated methods currently used by Kotlin plugin
- Enable deprecation logging for deprecated methods currently used by Android plugin
- Make it possible to see all instances of a deprecation finding and not only the first one.
- Remove pre 5.6 Worker APIs
- Turn 'Using mustRunAfter/shouldRunAfter/finalizedBy to reference tasks from another build' into an error
- Remove deprecated injecting the input artifact of a transform as a File
- Treat outputs with relative path sensitivity
- Remove `IncrementalTaskInputs`
- Class 'Foo' is compiled by a new Kotlin compiler backend and cannot be loaded by the old compiler
- Consolidate snapshotting missing elements in different file collections
- Nested finalizers should honor task order across projects
- Make `antlr` plugin support the configuration cache
- Make `init` plugin support the configuration cache
- Allow buildSrc to use and see other included builds
- `Provider.map { nullableValue }` in Kotlin DSL does not work
- Property 'xxx' with value '/tmp/bug.txt' cannot be serialized with RegularFileProperty
- Remove old artifact transform API
-Use worker API for built-in code quality tasks
-PMD custom rule set documentation unclear
-Warn if a class used in injection is not static
-Can't easily run junit tests in buildSrc
-Move stale output cleanup to execution engine
-Remove --no-rebuild
-Convert `buildSrc` to be an implicit, included build
-Command-line init scripts not executed against `:buildSrc` project
- Rectify Java toolchain related shortcomings
- Gradle 8 compiled plugins are not usable with Gradle <7
- Add SAM with receiver and compiler settings link to the Gradle Kotlin DSL page under the `kotlin-dsl` plugin
- Fix remaining TODOs in upgrade guide for 8.0
- 8.0 RC 1 regression: tartree does not work for .tar.gz files
- Gradle 8 upgrade docs missing for TestReport removals
- unzipped-distribution - Log4j Vulnerability on Enterprise File System Scans
- 8.0 RC 1 regression: CodeNarc plugin cannot resolve its dependencies
- Upgrade embedded Kotlin to 1.8.0
- Broken link title in "Migrating Builds From Apache Maven"
- Exception compiling Scala under Gradle 8
- NoSuchMethodError org.gradle.api.DefaultTask.getOnlyIf when trying to run plugin compiled with Gradle 7.6 with Gradle 7.5.1
- Build produces INFO log "Script 'build.gradle.kts' is not supposed to be used along with regular Kotlin sources, and will be ignored in the future versions by default."
- Cannot use nested `build-logic` as included build for build logic
- Build fails with configuration cache enabled: BuildServiceRegistration with name 'listener-service' not found
更新時間：2023-01-17
更新細節：