paulbakker released this
Nov 2, 2018
· 2 commits to master since this release
This bugfix release gets rid of several issues. The overview of closed issues can be found here:
Most importantly, resource loading now works correctly in tests and the application plugin.
Note that due to plugin portal changes, the installation instructions for the plugin are now slightly different (notice the classpath is no longer prefixed with gradle.plugin.
paulbakker released this
Oct 25, 2018
· 3 commits to master since this release
This release contains several new major features and a number of fixes and minor improvements.
Previously the javadoc plugin was not able to run for a modular project, because the module path was not configured correctly. This release supports the javadoc plugin. Configure the plugin as usual, you should not need any module specific parameters.
All tasks supported by this plugin (compile, compileTest, test, javadoc, dist and run) now support DSL to configure extra modules to be added. This is useful to explicitly add modules that are not configured in your Gradle dependencies. The following is an example that explicitly adds the java.sql module, which is provided by the JVM, to the module graph in the run configuration.
addModules = ['java.sql']
This feature (together with several other patches) was contributed by @sormuras.
Support for a build-tool agnostic module-info.test text file that contains the java command line options needed to make white-box testing work.
For more details about the idea see https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world#white-box-modular-testing-with-extra-java-command-line-options
An implementation can be was copied from here:
Motivation Why should white box testing "feel and code" different than black box testing? Why use "command line flags" or "magic build tool support" when there already exist a general purpose "DSL" for describing your modular (testing) setup? See this Maven Blueprint for a brief overview and the entire
section for an detailed explanation.
In short: use the default module description syntax to a) shadow the main configuration and b) express additional requirements needed for testing in a regular module-info.java file. But, as most build tools and IDEs don’t support two module descriptors on the path, nor do they understand module descriptors sharing a single name, the module-info.test approach is enabling the test author to stay in the modular world.