This paves the way for publishing Gradle module metadata once the
problem caused by snapshot versions and our two-step publication
process has been addressed.
See gh-19609
This reverts commit b34a311d02 as,
having disabled the publishing of Gradle's module metadata (4f75ab5),
the changes are no longer needed.
See gh-19609
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.
See gh-19609
This commit maps 'spring.cache.redis.key-prefix' to the new
'prefixCacheNameWith' method introduced in Spring Data Neumann. This
makes sure that the configured prefix includes the cache name.
Closes gh-16676
Previously, enforcedPlatform dependencies were using to pull in the
constraints defined in spring-boot-dependencies and
spring-boot-parent and applied them strictly so that the constrained
version had to be used. This worked as intended in Spring Boot's own
build but incorrectly enforced those same strict version requirements
on external consumers of Spring Boot's modules.
This commit reworks how Spring Boot defines its internal dependency
management so that platform dependencies are exposed to external
consumers while enforced platform dependencies are using internally.
See gh-19609
Andy Wilkinson
Stephane Nicoll
dreis2211
Madhura Bhave
Dmytro Nosan
Brian Clozel
Phillip Webb
Scott Frederick