Skip to content

Releases: java9-modularity/gradle-modules-plugin

1.1.1 bugfix release

02 Nov 17:15
@paulbakker paulbakker
v1.1.1
a4a3bd1
Compare
Choose a tag to compare
1.1.1 bugfix release

This bugfix release gets rid of several issues. The overview of closed issues can be found here:

https://github.com/java9-modularity/gradle-modules-plugin/milestone/2?closed=1

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.

buildscript {
  repositories {
    maven {
      url "https://plugins.gradle.org/m2/"
    }
  }
  dependencies {
    classpath "org.javamodularity:moduleplugin:1.1.1"
  }
}
Assets 2
Loading

1.1.0

25 Oct 23:10
@paulbakker paulbakker
v1.1.0
8087111
Compare
Choose a tag to compare
1.1.0

This release contains several new major features and a number of fixes and minor improvements.

Support for the Javadoc plugin

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.

javadoc {

}

DSL for --add-modules

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.

run {
   moduleOptions {
        addModules = ['java.sql']
    }
}

Support for module-info.test

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:

https://github.com/sormuras/junit-platform-maven-plugin/blob/92239b39d7d1112cf25f0b37287d38605d1f09ed/src/main/java/de/sormuras/junit/platform/maven/plugin/Patcher.java#L37-L63

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 🔥module-info.[java|test]🔥 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.

Assets 2
Loading