kotlin-dsl-plugins

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Bump `kotlin-dsl` plugin version

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

  1. … 1 more file in changeset.
Bump `kotlin-dsl` plugin version

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

  1. … 1 more file in changeset.
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>

Bump `kotlin-dsl` plugin version

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

  1. … 1 more file in changeset.
Bump `kotlin-dsl` plugin version

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

  1. … 1 more file in changeset.
Bump `kotlin-dsl` plugin version

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

  1. … 1 more file in changeset.
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>

  1. … 6 more files in changeset.
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>

  1. … 6 more files in changeset.
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>

  1. … 6 more files in changeset.
Fix tests in Kotlin DSL subprojects

  1. … 4 more files in changeset.
Fix tests in Kotlin DSL subprojects

  1. … 4 more files in changeset.
Fix tests in Kotlin DSL subprojects

  1. … 4 more files in changeset.
Fix tests in Kotlin DSL subprojects

  1. … 4 more files in changeset.
Build buildSrc after applying the settings file (#10305)

Fixes #9094 and #5333

  1. … 54 more files in changeset.
Bump `kotlin-dsl` plugins version

Signed-off-by: Rodrigo B. de Oliveira <rodrigo@gradle.com>

  1. … 1 more file in changeset.
Update kotlin tests (3)

Adjust tests and samples to new metadata sources defaults

  1. … 95 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

  1. … 32 more files in changeset.
Remove 'experimental' variant from dependency resolution tests

With the 'GRADLE_METADATA' feature preview gone, we now only have

two dimensions of variation to test:

(1) Ivy or Maven repository?

(2) Gradle metadata available - in addition to pom or ivy - or not?

If Gradle 6+ was used for publishing, Gradle metadata is most likely

available and the pom/ivy file contains the corresponding marker.

If an older Gradle version (or Maven/Ivy) was used for publishing,

Gradle metadata is not available and there is also no marker in the

other metadata file.

  1. … 32 more files in changeset.
Ignore failing test temporarily

Ignore failing test temporarily

Ignore failing test temporarily

Bump `kotlin-dsl-plugins` version

  1. … 1 more file in changeset.
Bump `kotlin-dsl-plugins` version

  1. … 1 more file in changeset.
Remove usage of `replaceLogger` and deprecate `KotlinDslPluginOptions.experimental`

  1. … 3 more files in changeset.
Remove usage of `replaceLogger` and deprecate `KotlinDslPluginOptions.experimental`

  1. … 3 more files in changeset.
Update kotlin plugin test versions to compatible versions

  1. … 1 more file in changeset.