Cache descriptions in a location outside CLASS_OUTPUT so that Gradle's
incremental compilation does not lose javadoc-based descriptions for
types passed as .class files.
See gh-50489
Signed-off-by: Agustin Bereciartua <bereciartua.agustin@gmail.com>
Packager#isCycloneDxBom only recognized CycloneDX SBOMs beneath
META-INF/sbom/. In a war, the CycloneDX Maven plugin's output is
packaged beneath WEB-INF/classes/META-INF/sbom/, so repackaging did
not add the SBOM manifest attributes.
Also check beneath Layout#getClassesLocation(), which findMainMethod
already uses to locate application classes. Continue to support the
root location used by jars.
Signed-off-by: COBI-98 <tkdgus968@naver.com>
See gh-51551
This commit improves TestImage so that an explicit image can trigger
the creation of the container, with optional additional setup. This
removes the need of creating additional container types for images that
have multiple flavors, and to please the static method that can only
create a container based on a single match.
Closes gh-51082
This commit reverts partially what was done in gh-49397 to let docker
tests have access to additional maven repositories. Unfortunately, maven
build executions with the Spring Boot Maven Plugin do not use the BOM
for dependency management. As such, if one of the dependency requires
a dependency that has not been prepared in the local repository, it will
need to be able to download it from the relevant repository.
This is the case with spring-core that the maven plugin depends on when
Spring Framework and Spring Boot do not use the same Micrometer version:
the build prepares the version that Spring Boot uses, but the build
execution attempts to download the one that Spring Framework relies on.
Closes gh-51266
MainClassFinder.findSingleMainClass(JarFile, ...) does not close the
JarFile; the caller owns the resource. FindMainClass passed a newly
opened JarFile without closing it, unlike sibling call sites that use
try-with-resources.
See gh-50949
Signed-off-by: Sebastien Tardif <sebtardif@ncf.ca>
Previously, Spring Boot's Gradle plugin reacted to the Protobuf
plugin by configuring Protobuf's grpc plugin. This worked well for
projects using gRPC but went too far for those using Protobuf
without gRPC.
This commit dials the support back a little bit. Now, our recommended
gRPC defaults are only applied when Protobuf is configured with the
grpc plugin.
Closes gh-50822
Update `ProtobufPluginAction` to align the protoc version with
`protobuf-java` rather than `protobuf-java-util`. The util
jar is only required for server gRPC code.
See gh-50405
Signed-off-by: Dongliang Xie <dragonfsky@gmail.com>
Andy Wilkinson
Agustin Bereciartua
Moritz Halbritter
Stéphane Nicoll
dependabot[bot]
Phillip Webb
COBI-98
Tran Ngoc Nhan
Manu Sridharan
Sebastien Tardif
Yanming Zhou
Doehyun Baek
Dongliang Xie