Comment From: wilkinsona

The use of enforced platform is too strict, particularly in the Gradle plugin where it causes the following failure in a Gradle Kotlin project:

   > Could not resolve org.jetbrains.kotlin:kotlin-stdlib-common:{strictly 1.3.50}.
     Required by:
         project :
      > Cannot find a version of 'org.jetbrains.kotlin:kotlin-stdlib-common' that satisfies the version constraints: 
           Dependency path ':demo:unspecified' --> 'org.jetbrains.kotlin.jvm:org.jetbrains.kotlin.jvm.gradle.plugin:1.3.61' --> 'org.jetbrains.kotlin:kotlin-gradle-plugin:1.3.61' --> 'org.jetbrains.kotlin:kotlin-stdlib:1.3.61' --> 'org.jetbrains.kotlin:kotlin-stdlib-common:1.3.61'
           Constraint path ':demo:unspecified' --> 'org.springframework.boot:spring-boot-gradle-plugin:2.3.0.BUILD-SNAPSHOT' --> 'org.springframework.boot:spring-boot-dependencies:2.3.0.BUILD-SNAPSHOT' --> 'org.jetbrains.kotlin:kotlin-bom:1.3.61' --> 'org.jetbrains.kotlin:kotlin-stdlib-common:1.3.61'
           Constraint path ':demo:unspecified' --> 'org.jetbrains.kotlin:kotlin-stdlib-common:{strictly 1.3.50}' because of the following reason: Pinned to the embedded Kotlin

Gradle requires Kotlin 1.3.50 for the version of Kotlin on the build script classpath, and Boot's Gradle plugin requires 1.3.61 via it enforcing the spring-boot-dependencies platform. That's too strong an opinion for the Gradle plugin to have.

Comment From: wilkinsona

https://github.com/spring-projects/spring-boot/commit/c66d2e8039be25e1cd40307d1e356f6c533205b4 hasn't resolved the problem. We're still using enforcedPlatform in other places which continues to constrain the version of Kotlin too strictly.

Comment From: wilkinsona

Regrettably, I think we might have to defer this from M1. The way in which we deploy the artifacts (publishing to a Maven repository on the filesystem and then using the Concourse artifactory resource to upload them) is incompatible with Gradle's module metadata generation.

The metadata contains an entry, url that contains the name of the artifact. This will be something like spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. The -1 in the name is derived from the Maven snapshot build number. It's -1 as the local repository to which the artifact is published is empty and has no maven-metadata.xml file. When the artifact is uploaded to Artifactory there is a maven-metadata.xml file so the build number is different. As a result, the module metadata points to a file that doesn't exist. This leads to problems like this when trying to consume the snapshots:

Could not find spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1-2.3.0.BUILD-SNAPSHOT.jar (org.springframework.boot:spring-boot-gradle-plugin:2.3.0.BUILD-SNAPSHOT:20200114.101952-123)

Gradle has used the maven-metadata.xml file on the server to determine that 2.3.0.BUILD-SNAPSHOT:20200114.101952-123 is the latest version. It has downloaded the .module file with this version but it points to spring-boot-gradle-plugin-2.3.0.BUILD-20200114.095038-1.jar. That file doesn't exist so the build fails.

Comment From: wilkinsona

Some changes have been made in Gradle 6.2 that mean that this should hopefully work now. We should try publishing some snapshots with Gradle's module metadata and see how things go.

Comment From: no-simpler

@wilkinsona

I am on Gradle 6.7, and when I add the Spring Boot plugin 2.3.5.RELEASE, the publish task stops generating Gradle Metadata.

build.gradle

plugins {
    id 'org.springframework.boot' version '2.3.5.RELEASE'
    id 'io.spring.dependency-management' version '1.0.10.RELEASE'
    id 'java'
    id 'maven-publish'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter'
    testImplementation('org.springframework.boot:spring-boot-starter-test') {
        exclude group: 'org.junit.vintage', module: 'junit-vintage-engine'
    }
}

test {
    useJUnitPlatform()
}

publishing {
    repositories {
        mavenLocal()
    }
    publications {
        create('bootJava', MavenPublication) {
            artifact bootJar
        }
    }
}

The output of gradle publish:

23:43:26: Executing task 'publish'...

> Task :dcl-control-app:compileJava
> Task :dcl-control-app:processResources NO-SOURCE
> Task :dcl-control-app:classes
> Task :dcl-control-app:bootJar
> Task :dcl-control-app:generatePomFileForBootJavaPublication
> Task :dcl-control-app:publishBootJavaPublicationToMavenLocalRepository
> Task :dcl-control-app:publish

BUILD SUCCESSFUL in 963ms
4 actionable tasks: 4 executed
23:43:27: Task execution finished 'publish'.

Is this the intended behavior?

Comment From: wilkinsona

@no-simpler No, that's not the intended behaviour. If you believe you've found a bug, please open a new issue and provide a minimal sample that reproduces the problem. You can share the sample with us by zipping it up and attaching it to the issue that you create or by pushing it to a separate repository on GitHub.