v1.8.3

• issue #186: JUnit Params problem in 1.8.1

v1.8.2

• issue #186: JUnit Params problem in 1.8.1

v1.8.1

• fix NPE in TestEngine.java

v1.8.0

New features and bug fixes in this release:

• #182: Gradle 7.0 compatibility
• #140: Support gradle test fixtures
• #71: Consider transitive dependencies when resolving TestEngine
• #161: Fix sample projects for JUnit 5.5.x support
• #172: TestNG has the wrong module name for versions 7.0.0 and above
• #170: Gradle 6.5 javadoc task, addExports is not working
• #175: JUnit Params not detected
• #177: Readme: fixed Reference to compileModuleInfoSeparatly
• #179: Migrate from Travis to GitHub Actions
• #184: Gradle 7: test.moduleOptions.runOnClasspath doesn't work for test compilation

Thanks to @MariusVolkhart and @martilidad for their contributions to this release!

v1.7.0

This release adds a few new features and fixes several issues. Some of them are:

• #1 - Introduce support for the Spock Testing framework
• #33 - Support for Eclipse plugin
• #65 - unexpected arguments in main
• #93 - Patch module does not handle multiple jars
• #111 - Since 1.6.0 - "error: file should be on source path, or on patch path for module"
• #112 - Print warning when using with Gradle < 5
• #123 - Adding support for additional test frameworks (Mockito, EasyMock, AssertJ, JUnit 5.5.x)
• #124 - No way to set module version?
• #130 - Add support for new junit-jupiter artifact ID of JUnit 5
• #132 - compileJava tasks fails in gradle 6.1
• #143 - Gradle multiproject fails to find automatic-module-name with dependency on java-library.
• #154 - make plugin compatible with Gradle 6.4
• #156 - Circular dependency in complex project (in compileModuleInfoJava)

Thanks to @Alfred-65 and @bredmold for their contributions to this release!

v1.6.0

Release 1.6.0 adds support for Groovy, and contains a number of improvements and bug fixes.

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

---

Note: #80 introduced minor potentially breaking changes for Kotlin DSL (= some imports need to be updated).

v1.5.0

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!

v1.4.0

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"
]

v1.3.0

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

v1.2.1

This release contains a single fixed: #40