Skip to content

@paulbakker paulbakker released this Apr 4, 2019 · 7 commits to master since this release

Two major features have been added in this release:

  • Support for creating libraries that also target older Java releases (contributed by @tlinkowski)
  • DSL support for --add-reads,-opens,-exports (contributed by @aalmiray)

Support for creating libraries that also target older Java releases

This feature is for library maintainers that want to include a module-info.java for users who are on modern Java versions, but also still need to maintain support for older Java versions that don't support modules.
The feature includes a DSL to configure what Java releases to target and is explained in detail in the docs: https://github.com/java9-modularity/gradle-modules-plugin#compilation

Thanks to @tlinkowski for contributing this work!

DSL support for --add-reads,-opens,-exports

New DSL options are supported to explicitly set flags such as for compiling, running and testing modules. Details are described in the docs https://github.com/java9-modularity/gradle-modules-plugin#monkeypatching-the-module.

Thanks to @aalmiray for contributing this work!

Assets 2
Feb 6, 2019
Revert "Relocate JavaParser classes (#58)"
This reverts commit c28e3ed
Dec 28, 2018

@paulbakker paulbakker released this Dec 28, 2018 · 29 commits to master since this release

This release contains support for configuring --patch-module easily to work around split package issues, and a number of bug fixes.

Happy holidays!

Patching modules to prevent split packages

The Java Platform Module System doesn't allow split packages.
A split package means that the same package exists in multiple modules.
While this is a good thing, it can be a roadblock to use the module system, because split packages are very common in (older) libraries, specially libraries related to Java EE.
The module system has a solution for this problem by allowing to "patch" modules.
The contents of a JAR file can be added to a module, by patching that module, so that it contains classes from both JARs.
This way we can drop the second JAR file, which removes the split package.

Patching a module can be done with the --patch-module module=somelib.jar syntax for the different Java commands (javac, java, javadoc, ...).
The plugin helps making patching easy by providing DSL syntax.
Because patching typically needs to happen on all tasks the patch config is set in the build.gradle file directly.

In this example, the java.annotation module is patched with the jsr305-3.0.2.jar JAR file.
The plugin takes care of the following:

  • Adding the --patch-module to all Java commands
  • Removing the JAR from the module path
  • Moving the JAR to a patchlibs folder for distribution tasks
patchModules.config = [
        "java.annotation=jsr305-3.0.2.jar"
]
Assets 2

@paulbakker paulbakker released this Dec 3, 2018 · 42 commits to master since this release

Kotlin support

This release introduces Kotlin support, contributed by @siordache.
Find an example project using Kotlin here: https://github.com/java9-modularity/gradle-modules-plugin/tree/master/test-project-kotlin

Assets 2

@paulbakker paulbakker released this Nov 21, 2018 · 44 commits to master since this release

This release contains a single fixed: #40

Assets 2

@paulbakker paulbakker released this Nov 2, 2018 · 56 commits to master since this 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

@paulbakker paulbakker released this Oct 25, 2018 · 78 commits to master since this release

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
You can’t perform that action at this time.