Restore the 'javax.xml.bind:jaxb-api' exclusion from `xmlunit-core`
which is actually required when using Maven on Java 9+.
The `CheckClasspathForUnnecessaryExclusions` cannot deal with profile
specific dependencies so an exception has been hard coded.
See gh-28332
Previously, the project version was used while filtering the apps
source during syncing but it was not considered as an input to
the task. This could result in the syncing being skipped even though
the project's version had changed.
This commit introduces a new custom task to make the configuration
more declarative and to allow the necessary input configuration to be
done in a single place.
Closes gh-28197
Previously, the optional configuration was added to the compile and
runtime classpaths of each source set and the the javadoc classpath
as well. This had a few disadvantages, the most notable of which is
that it meant that the configuration was ifrst resolved and then
the outcome of the resolution was added to the compile and runtime
classpaths. As a result, none of the attributes on the compile and
runtime classpaths were considered to influence variant selection.
This commit reworks the optional dependencies plugin so that the
compile and runtime classpaths of each source set are now configured
to extend from the optional configuration. This allows each
classpath configuration's attributes to influence the dependencies
that are selected from the optional configuration during resolution.
For example, when resolving the compile classpath, compile
dependencies (Usage.JAVA_API) will be selected and when resolving the
runtime classpath, runtime dependencies (Usage.JAVA_RUNTIME) will be
selected.
The above-described change means that runtime dependencies of an
optional dependencies will no longer leak into the compile classpath.
As a result of this, our Gradle plugin's test infrastructure has
been updated so that it no longer references runtime dependencies of
the Kotlin Gradle plugin at compile time.
Closes gh-27965
Previously, our conventions configured the source and target
compatibility on the project's JavaCompile tasks. This causes the
settings to be missed when importing the projects into Eclipse [1].
This commit updates the conventions to set the source and target
compatibility on the project-wide JavaPluginExtension. This allows
the Eclipse import to correctly detect and honour the settings.
Closes gh-26932
[1] https://github.com/eclipse/buildship/issues/978
The previous workaround worked but prevented caching of every test
task as the value of system property pointing to the custom security
properties file varied from build to build.
This commit refines the workaround to copy the file into the build
directory of the test task's project and reference it using a URL
that's relative to the task's working directory. This ensures that
the value of the system property doesn't change from build to build.
Closes gh-26252
Previously a number of file- or directory-based task inputs were
configured with specifying their path sensitivity. This meant
that the default absolute path sensitivity was used. For caches
that are cacheable this would result in a cache miss when the
inputs were identical other than being located at a different
absolute path as they are when running a CI build vs a local build.
This commit updates the configuration of additional task inputs
to use relative path sensitivity. A property name for each input has
also been configured. This makes them easier to identify in build
scans.
Closes gh-26270
sun.security.x509.AlgorithmId.get(String) isn't thread-safe and can
lead to null be returned for an algorithm that should be present.
This commit aims to work around this problem by avoiding the call
to AlgorithmId.get(String). It does so by configuring the
PKCS12 key protection algorithm to one that starts with
pbewithhmacsha (case insensitive). This short-circuits the logic
in PKCS12KeyStore.mapPBEAlgorithmToOID(String) and avoids the call to
AlgorithmId.get(String). Thanks again to @dreis2211 for the
suggestion.
The work around is only used when building with Java 8 as the problem
was fixed in Java 9.
Closes gh-26252
Andy Wilkinson
Phillip Webb
izeye
dreis2211
Stephane Nicoll