K-Lite Codec Tweak Tool 歷史舊版本 Page4

更新時間：2020-08-23
更新細節：

更新時間：2020-08-07
更新細節：

更新時間：2020-08-01
更新細節：

更新時間：2020-06-18
更新細節：

What's new in this version:

- Add function, search and delete history

更新時間：2020-06-18
更新細節：

更新時間：2020-06-04
更新細節：

更新時間：2020-05-16
更新細節：

更新時間：2020-05-16
更新細節：

What's new in this version:

Building, testing and running Java Modules:
- With this release, Gradle supports the Java Module System with everything you need to compile and execute tests for Java modules. You can also build Javadoc and run applications
- While there is some overlap with Gradle's dependency management features, Java Modules offer additional features like module boundaries that are enforced by the Java runtime

The only thing you need to configure is module path inference for the Java plugins:
- java {
- modularity.inferModulePath.set(true)
- Then you just need to make sure that you write a proper Java module by providing a module-info.java descriptor as part of your sources:
- src
- +-- main
- +-- java
- +-- module-info.java
- For more details, head over to the documentation on building modules, building modular applications and testing modules.
- Also feel free to explore the samples

Precompiled Groovy DSL script plugins:
- Script plugins are a convenient way to split up and organize a long build script, but they have some limitations and quirks. Kotlin DSL introduced precompiled script plugins that look like regular build scripts but have all of the advantages of binary plugins. They can:
- be published to a private repository or the Plugin Portal,
- be tested using TestKit,
- be applied using the plugins {} block,
- use the plugins {} block to apply other plugins
- Gradle now allows precompiled script plugins to be written using the Groovy DSL in addition to the Kotlin DSL
- For example, a Gradle script in buildSrc/src/main/groovy/my-plugin.gradle can be used as a plugin in the main project as plugins { id 'my-plugin' }
- Precompiled script plugins are covered in more depth in the user manual. There is also a sample available that demonstrates the feature in action

Single dependency lock file per project:
- Dependency locking is a mechanism for creating reproducible builds even when using dynamic dependency versions. This release adds an improved dependency locking file format that results in fewer lock files in most projects that use this feature. In addition, when using this format, the lock file name and location can be configured
- This format will become the default lock file format in Gradle 7.0. For now, it is required to opt-in to use it
- Take a look at the documentation for more information and how to enable the feature

Better dependency variant matching error messages:
- Gradle provides a powerful variant-aware dependency management engine
- This release introduces clearer variant matching error messages for the JVM ecosystem
- In previous releases, these error messages could be difficult to understand and sometimes lacked enough context to figure out what to do. Gradle 6.4 improves these error messages by making them more human-readable and introducing colors to the console to highlight problems.

Improvements to PMD code quality plugin:
- Incremental analysis is enabled by default
- As of Gradle 6.4, the PMD plugin uses incremental analysis by default. This can significantly reduce analysis time on subsequent builds.
- For builds relying on a version of PMD older than 6.0.0, you will need to explicitly disable incremental analysis.
- Specify number of violations required before the build fails
- The PMD plugin now lets you set the number of violations before the build fails. This can make it easier to introduce PMD into existing projects that may initially have many violations.
- If you wanted to fail the build if the number of violations is above 150, you can set maxFailures to 150.
- pmd {
- maxFailures = 150
- This was contributed by Matthew Duggan.
- Security warning about using DEBUG level logging
- Potentially sensitive information is logged when Gradle is executed with debug level logging, such as sensitive credentials, authentication tokens or internal repository URLs. Much of this logging occurs deep in components of the JVM and other libraries outside the control of Gradle. While debugging, this information may be inherently useful. However, this information can be unintentionally exposed when Gradle builds are executed on Continuous Integration services where build logs are publicly-accessible. See the recent update about the fixed Plugin Portal vulnerability for an example of this security risk.
- Gradle now warns users about the risks of using DEBUG level logging.
- We recommend plugin maintainers avoid logging sensitive information if possible, and if it's not possible, that all sensitive information be logged exclusively at the DEBUG log level.

Fixed issues:
2 issues have been fixed in Gradle 6.4.1.
[#13069] - Regression: Different daemons are used between IDE and CLI builds for the same project
[#13057] - Regression: Main-Class attribute always added to jar manifest when using application plugin

更新時間：2020-05-06
更新細節：

What's new in this version:

- Mapping of Ivy files to variants should handle configuration level excludes
- Upgrade to native platform milestone for 6.4
- Investigate timeouts with file watching enabled
- Rename 'modularClasspathHandling' properties to 'modularity'
- In version constraints, the order of `prefer X` vs `strict Y` matters
- Perform module path derivation in Eclipse IDE sync
- Potential deadlock when using the worker API and not using the Gradle daemon
- Add module path support to CreateStartScripts tasks of application plugin
- Add modular classpath handling configuration to Java extension
- Document JPMS support
- Build service installed via init script closes prematurely when `:buildSrc` sub-build is finished
- Dependency ordering issue when upgrading to Guava 28.2-jre
- exclusiveContent API does not work with Kotlin Gradle DSL
- Configuring the Jar task's manifest gives an Incubating warning
- Register watchers for newly added file locations during the build
- Basic JPMS support for generating Javadoc
- Basic JPMS support for executing Java modules
- Basic JPMS support for testing Java modules
- GenerateModuleMetadata writes wrong file names in case of customized artifact publications.
- Basic JPMS support for compiling Java modules
- File change not recognized by VFS on Windows when entire watched directory is removed
- Improve the dependency lockfile format
- StackOverflowError in ManagedPropertyName.getDisplayName()
- Expose Repository MetadataSources
- ScalaCompile task does not respect all JavaForkOptions configuration
- java-library plugin makes impossible to have project dependency on Java9-modular kotlin project
- Add a method to specify Scalac plugins in ScalaCompile without breaking build cache
- [JPMS] Accessing resources when Java application run via JavaExec task
- Lockfile location/filename should be customizable
- Packaging test code in a separate JDK 9 module fails with IllegalArgumentException: superClassName is empty
-Java 9: Support Jigsaw modules in JavaExecAction
-Running tests against JDK 9 module causes accessibility issues
-Support setting Jigsaw module version in jar task
- Gradle 6.4-rc-1 triggers compileJava when project version is changed in multi-module project
- Cached component metadata rules leak memory
- Gradle 6.4-rc-1 breaks bootRun
- Traditional convention mappings do not work anymore for JavaExec.main
- Stack overflow in Gradle 6.4-rc-1, regression from 6.3
- Invalid equals breaks fix for cache memory leak
- Single lock file changes on generation without external change
- Potential race condition when task has a property whose value is derived from mapped dependency resolution results
- Race condition when a `Property` instance is used by multiple tasks and has a value derived from a dependency resolution result

更新時間：2020-03-25
更新細節：

What's new in this version:

Improved error messages:
Show location of Java fatal error log:
- When the Java virtual machine executing the Gradle daemon crashes unexpectedly, the Java virtual machine will generate a fatal error log. The crash could be due to a bug in Java, Gradle itself, or in the user code being executed.
- Since it may be hard to find where this error log is written, Gradle now prints the location of the crash log to the console

Support for Java 14:
- Gradle now supports running and building with Java 14.

Fixed:
- Deprecate 'default' and 'archives' configurations for resolving and declaring dependencies
- Show path of hs_err_pid file when daemon disappears
- Update documentation to not point to samples or snippets in -all distribution
- De-serialization of task graph incorrect for anonymous subtypes of enum.
- Gradle crashes if GRADLE_RO_DEP_CACHE is set and it cannot create modules-2 directory within it
- Checkstyle task can no longer be configured to analyse single files
- Precompiled script plugin fails to build on Windows if script is saved with CRLF (accessors not resolved)
- Daemon crashes for `ArtifactTransformInputArtifactIntegrationTest` with VFS retention enabled
- C++ compilation doesn't pick up file changes when VFS retention is enabled
- `GradleBuildTaskIntegrationTest.can run multiple GradleBuild tasks concurrently` fails with VFS retention
- Deleting local state when loading from cache is not picked up with partial invalidation
- Fix `PlayContinuousBuildReloadWaitingIntegrationTest` with VFS retention
- The `clean` task does not report changes to VFS
- Parsing gradle properties file with invalid syntax fails with unhelpful error message
- Log individual input file fingerprints
- Allow war task to be made cacheable with runtime api
- com.fasterxml.jackson.core:jackson-databind Security Vulnerabilities in Gradle 6.x
- Enable VFS retention for the build-tool build
- Enable VFS retention for local builds only
- Incremental Java compilation doesn't clean up stale generated JNI headers
- Add access to POM packaging in component metadata rules
- Re-evaluate VFS retention tests after known issues are fixed
- Instant execution fails on Java Compile Task (no source) when there are only kotlin files in src/main/java
- Handle all macOS file events without dropping VFS
- File change not recognized by VFS on macOS when entire watched directory is removed
- Watch long paths on Windows
- Implement event-driven file watcher for Linux
- JDK 14 support
- ServiceRegistry failures should emit clearer help messages
- Provide default value for JavaCompile header output
- Constraints can sometimes impact excludes
- CalculateTaskGraphBuildOperationType emits mutated structure for task plan
- Same dependencies with different classifiers are not consumed correctly from Gradle Module Metadata