Changelog.computeDifferences() called
ConfigurationMetadataRepository.getAllProperties() from inside its main
loop. The default repository implementation builds a new map each time
that method is called, so the new version's properties were rebuilt once
per property of the old version. The ids that had already been seen were
also tracked in an ArrayList, turning each membership check into a linear
scan.
Read the properties of each repository once and use the old properties
map itself to detect the properties that have been added.
Computing the changelog between Spring Boot 3.4.0 and 3.5.0 (2,498 and
2,555 properties) drops from 203ms to 0.5ms and the generator's peak
memory from 302MB to 91MB. The generated asciidoc is byte for byte
identical.
See gh-51655
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Baggage is already propagated over gRPC by the auto-configured
Micrometer observation interceptors: on the server side the
ObservationGrpcServerInterceptor hands the incoming metadata to the
tracing observation handlers, which extract the W3C baggage header as
well as the individual metadata keys listed in
management.tracing.baggage.remote-fields, and on the client side the
ObservationGrpcClientInterceptor writes them to the metadata of
outgoing calls. This was not documented, and it is easy to miss that
it requires micrometer-core on the classpath.
This commit adds an Observability section to the gRPC server
documentation, extends the gRPC client Observability section, and
mentions gRPC in the baggage section of the tracing documentation.
See gh-51597
Signed-off-by: Oleksandr Shevchenko <oleksandr.shevchenko@datarobot.com>
LayersIndex.Node kept its children in a list and scanned that list
linearly to find the child for each path segment. Building the index is
therefore O(entries x siblings), a cost that is dominated by the largest
flat directory in the jar: BOOT-INF/lib/ for the dependencies, and any
bundled resource directory such as a front-end build output.
Keep the children in a LinkedHashMap keyed by the segment name so that
lookups are constant time. Insertion order is preserved, so the order in
which buildIndex() walks the tree is unchanged.
For a jar with 32,529 entries, 426 dependencies and a 12,000 file static
resource directory, this reduces the number of string comparisons from
73.7M to 222K and the time spent building the index from 197ms to 12ms.
For a jar with no large flat directory (20,529 entries, 426
dependencies) the gain is much smaller: 1.58M comparisons to 162K, and
12.5ms to 9.6ms. The generated layers.idx is byte for byte identical in
both cases.
See gh-51654
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
IndexedLayers.getLayer() walked every entry of layers.idx for each jar
entry being extracted, making extraction O(entries x index size). The
dependency entries are listed first while the application classes are
covered by a single directory entry near the end, so the most numerous
entries consistently scanned the longest.
Index the candidates once when the index file is read, keeping the
directory candidates in a separate map that preserves index order. A
file name is then resolved with a single map lookup and only the
handful of directory candidates has to be scanned.
For a jar with 24,823 entries and 700 dependencies this reduces the
number of string comparisons from 17,179,582 to 72,946 (106.9ms to
2.5ms). With 4,173 entries it goes from 1,019,857 to 11,896 (5.4ms to
0.1ms) and with 903 entries from 70,612 to 2,426 (0.8ms to 0.1ms).
Lookups resolve to the same layer as before. LayersIndex only writes a
name once its whole subtree belongs to a single layer, so no indexed
name is a prefix of another and at most one candidate can match, which
makes the order the two kinds of candidate are consulted in immaterial.
See gh-51653
Signed-off-by: Junggi Kim <kimjg2477@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.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
Gradle 9.6 deprecates Project.getProperties, which will be removed
in Gradle 10.
Use ProviderFactory.gradleProperty to read the required properties
in AntoraAsciidocAttributes and the image system tests build script.
Preserve null handling for missing Antora properties and fall back
to the project version when springBootVersion is not configured.
Update the provider mocks and add tests for the GraalVM
plugin version attribute.
Signed-off-by: Hyunwoo Jung <hyunwoojung@kakao.com>
See gh-51635
Gradle 9.6 deprecated the implicit lookup of properties in parent
projects, which currently causes the build to emit deprecation
warnings and will become an error in Gradle 10.
The settings script for the gradle/plugins build sets properties
from the root gradle.properties file only on its root project. The
cycle-detection-plugin subproject then resolves javaFormatVersion
and checkstyleToolVersion by walking up to its parent, which
triggers the deprecation.
This commit uses GradleLifecycle#beforeProject rather than
Gradle#rootProject so that the properties are defined directly on
every project in the build. As an isolated action, it also avoids
carrying the settings script into each project's configuration,
which keeps the build friendlier to the configuration cache.
It also enables the NO_IMPLICIT_LOOKUP_IN_PARENT_PROJECTS feature
preview so that any reintroduction of the deprecated behavior fails
the build rather than only emitting a warning.
Signed-off-by: Hyunwoo Jung <hyunwoojung@kakao.com>
See gh-51625
The deprecation entry for
management.prometheus.metrics.export.pushgateway.base-url was declared
as "management.promethus", so the deprecation was never reported.
Signed-off-by: ohchanKyu <okc0202@naver.com>
See gh-51627