Update `EphemeralBuilder` so that it adds an additional layer that
containing an empty application (aka workspace) directory owned by
the build user.
Prior to this commit, the directory was only bound. This could cause
issues on Podman where, unlike Docker, the bound directory is owned
by `root`.
Fixes gh-45233
This commit updates the conditions in Neo4jReactiveDataAutoConfiguration
so that it gracefully backs off if certain beans are not present, rather
than assuming its sibling Neo4jDataAutoConfiguration has run.
Closes gh-44930
Prior to this commit, certain rules, like BeanPostProcessor,
did not work with external classes. This commit ensures that
ArchRules are executed within a context ClassLoader that includes
all classes from the compile classpath.
See gh-45202
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
* pr/44866:
Polish "Document the semantic of using multiple profile expressions"
Document the semantic of using multiple profile expressions
Closes gh-44866
This commit clarifies the semantic of declaring multiple profile
expression with the "spring.config.activate.on-profile" property.
See gh-44866
Signed-off-by: Yanming Zhou <zhouyanming@gmail.com>
This commit updates jOOQ's DefaultExceptionTranslatorExecuteListener to
fallback on Spring Framework's default if no dbName is available.
See gh-44954
Signed-off-by: Dennis Melzer <dennis.melzer@de.bosch.com>
This commit addresses an issue where placeholders like {foo}
remain as {foo} if the message is the same as its code.
See gh-45212
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Update auto-configured `IntegrationMBeanExporter` to be created from
a static method since it's a post-processor. Relevant injection now
occurs by overriding the `afterSingletonsInstantiated()` method.
Closes gh-45186
Verification failures are generally failures which verify correctness,
e.g., failures caused by test, compilation, linting, etc.
Non-verification failures are generally failures related to the
build toolchain, e.g., failures caused by dependency resolution, build
configuration, etc.
Develocity attempts to classify failures based on context, but it
doesn't always classify correctly. By default, most failures are
classified as non-verification. By explicitly throwing a
`VerificationException` for verification task failures, the failures
will be appropriately classified.
See gh-45187
See also: https://docs.gradle.com/develocity/failure-classification
Signed-off-by: Eric Haag <ehaag@gradle.com>
Moritz Halbritter
Stéphane Nicoll
Phillip Webb
dependabot[bot]
florgust
Claudio Nave
Andy Wilkinson
Dmytro Nosan
Tran Ngoc Nhan
Yanming Zhou
Dennis Melzer
Johnny Lim
Eric Haag