Refine `buildSrc` so that `spring.mavenRepositories()` are considered
for all build types (not just milestones and snapshots). We now pass
"springFrameworkVersion" to `SpringRepositorySupport.groovy` so that
repo.spring.io doesn't get added for OSS builds using release artifacts.
Closes gh-46823
Previously, the Kotlin API docs included Java APIs. This commit
corrects this by suppressing all Dokkatoo source sets other than
main (main in src/main/kotlin, javaMain is src/main/java).
Dokkatoo is sensitive to the order in which plugins are applied. This
commit adapts to the sensitivity by changing the order in which
the Dokatoo and Kotlin JVM plugins are applied. This prevents the
Dokatoo plugin for overwriting the configuration that's applied by
our Kotlin conventions.
Closes gh-47763
Without this change, removing a file from the task's inputs would not
be reflected in its output as the stale output file for that input
would remain.
Closes gh-46970
Prior to this commit, it wasn't possible to write a test to verify that
a specific ArchRule applied only to a specific SourceSet.
This PR rewrites `ArchitectureCheckTests` to support different sources
and also adds functionality to configure the plugin.
With these changes, all tests now verify not only the
`checkArchitectureMain` task but also `checkArchitectureTest`.
See gh-46822
Signed-off-by: Dmytro Nosan <dimanosan@gmail.com>
Update `EclipseConventions` so that classpath `whenMerged` changes
are applied via `JavaBasePlugin`. Without this change, the `whenMerged`
item is added, but then`EclipsePlugin.configureEclipseClasspath` is
called from a `project.getPlugins().withType(JavaBasePlugin.class, ...`
call. Using a nested call appears to fix the issue, probably because
it now runs after `configureEclipseClasspath`.
Closes gh-46319
Previously, we called getCredentials() to determine whether or not a
repository requires authentication. Unfortunately, the method has the
unwanted side-effect of assigning empty username and password
credentials to a repository that previously did not require
authentication and did not, therefore, have any credentials. These
empty credentials can then cause subsequent failures because
"Username must not be null!".
There's no side-effect-free public API for accessing a repository's
credentials. Instead, we're using some internal API on
AuthenticationSupportedInternal. If this causes problems when
upgrading to a new version of Gradle a different approach will be
required. For example, we could pass in the repositories in two
separate collections: those that require authentication and those
that don't.
Closes gh-45950
Update the reference documentation to provide more details about the
three supported methods of starting Testcontainer containers.
See gh-44187
Signed-off-by: Vanio Begic <vanio.begic123@gmail.com>
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>
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>
Phillip Webb
Andy Wilkinson
Stéphane Nicoll
Tran Ngoc Nhan
Dmytro Nosan
Johnny Lim
Piyal Ahmed
Vanio Begic
Eric Haag