Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Support prefix and latest selectors in strictly

This was basically just about adding test coverage.

The assumed behavior is that `latest.release` would

accept _any_ version when used in a reject selector,

so that we can iterate on rejected versions until

we find a match.

Support prefix and latest selectors in strictly

This was basically just about adding test coverage.

The assumed behavior is that `latest.release` would

accept _any_ version when used in a reject selector,

so that we can iterate on rejected versions until

we find a match.

Extract method names into constants

and place them right to the methods. This should make it harder to forget

changing the method name next time.

Simplify test

It is only necessary to call the method in the constructor, the usage

of `@Nested` is not required.

Update released version to latest snapshot

Update library versions in build init to latest for 6.1

Clean accepted API changes

Clean release notes and welcome message for 6.1

    • -134
    • +3
    /subprojects/docs/src/docs/release/notes.md
Update version to 6.1

TeamCity change in 'Gradle / Check / Quick Feedback - Linux Only / Test Coverage - Quick Java12 Openjdk Linux' project: Custom chart PROJECT_EXT_20 was removed from project-graphs

TeamCity change in 'Gradle / Check / Quick Feedback - Linux Only / Test Coverage - Quick Java12 Openjdk Linux' project: New custom chart added to project-graphs

Publish 5.6.2-20190912230036+0000

Mention contributer in release note

    • -1
    • +2
    /subprojects/docs/src/docs/release/notes.md
Mention contributer in release note

    • -1
    • +2
    /subprojects/docs/src/docs/release/notes.md
Revert change to `gradlew`

Revert change to `gradlew`

Fix PrecompiledScriptPluginModelCrossVersionSpec

It was missing the repo declaration already required with the

`kotlin-dsl` plugin.

Signed-off-by: Paul Merlin <paul@gradle.com>

Fix PrecompiledScriptPluginModelCrossVersionSpec

It was missing the repo declaration already required with the

`kotlin-dsl` plugin.

Signed-off-by: Paul Merlin <paul@gradle.com>

Fix PrecompiledScriptPluginModelCrossVersionSpec

It was missing the repo declaration already required with the

`kotlin-dsl` plugin.

Signed-off-by: Paul Merlin <paul@gradle.com>

Fix EmbeddedKotlinPluginTest

The `embedded-kotlin` plugin now requires a repository to be declared.

Signed-off-by: Paul Merlin <paul@gradle.com>

Fix EmbeddedKotlinPluginTest

The `embedded-kotlin` plugin now requires a repository to be declared.

Signed-off-by: Paul Merlin <paul@gradle.com>

Fix EmbeddedKotlinPluginTest

The `embedded-kotlin` plugin now requires a repository to be declared.

Signed-off-by: Paul Merlin <paul@gradle.com>

Also add changes to Checkstyle to release notes

Ignore value of user provided config_loc in favor of configDirectory

This has been deprecated since May 2017

Bump `kotlin-dsl` plugin version

Signed-off-by: Paul Merlin <paul@gradle.com>

Bump `kotlin-dsl` plugin version

Signed-off-by: Paul Merlin <paul@gradle.com>

Bump `kotlin-dsl` plugin version

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove the embedded-kotlin-repository

It was based on ClientModule dependencies that caused more troubles than

anything. The main one being that the artificial dependency graph needed

to be kept up to date with each Kotlin version. Moreover since several

Kotlin versions, declaring a repository is necessary in any case. This

change simplifies the code and should make the runtime a bit faster.

However, the Kotlin dependencies when applying the `kotlin-dsl` plugin

are now required to be downloaded. This isn't a big change and should

only impact people using the `kotlin-dsl` plugin without depending on

Kotlin in other parts of their build. This could be alleviated in the

future if dependency resolution considers the Gradle install/distro as a

source of artifacts in the same way it uses maven local.

Along the way, the pinning of Kotlin dependencies to the embedded

version for the build scripts classpath has been moved from a resolution

rule to proper, faster, dependency constraints.

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove the embedded-kotlin-repository

It was based on ClientModule dependencies that caused more troubles than

anything. The main one being that the artificial dependency graph needed

to be kept up to date with each Kotlin version. Moreover since several

Kotlin versions, declaring a repository is necessary in any case. This

change simplifies the code and should make the runtime a bit faster.

However, the Kotlin dependencies when applying the `kotlin-dsl` plugin

are now required to be downloaded. This isn't a big change and should

only impact people using the `kotlin-dsl` plugin without depending on

Kotlin in other parts of their build. This could be alleviated in the

future if dependency resolution considers the Gradle install/distro as a

source of artifacts in the same way it uses maven local.

Along the way, the pinning of Kotlin dependencies to the embedded

version for the build scripts classpath has been moved from a resolution

rule to proper, faster, dependency constraints.

Signed-off-by: Paul Merlin <paul@gradle.com>

Remove the embedded-kotlin-repository

It was based on ClientModule dependencies that caused more troubles than

anything. The main one being that the artificial dependency graph needed

to be kept up to date with each Kotlin version. Moreover since several

Kotlin versions, declaring a repository is necessary in any case. This

change simplifies the code and should make the runtime a bit faster.

However, the Kotlin dependencies when applying the `kotlin-dsl` plugin

are now required to be downloaded. This isn't a big change and should

only impact people using the `kotlin-dsl` plugin without depending on

Kotlin in other parts of their build. This could be alleviated in the

future if dependency resolution considers the Gradle install/distro as a

source of artifacts in the same way it uses maven local.

Along the way, the pinning of Kotlin dependencies to the embedded

version for the build scripts classpath has been moved from a resolution

rule to proper, faster, dependency constraints.

Signed-off-by: Paul Merlin <paul@gradle.com>