You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Holger Haag (JIRA)" <ji...@apache.org> on 2019/07/07 09:20:00 UTC
[jira] [Updated] (MCOMPILER-393) Ignore module-info.java
[ https://issues.apache.org/jira/browse/MCOMPILER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Holger Haag updated MCOMPILER-393:
----------------------------------
Description:
Running unit test cases in modularized java projects has its own challenges (especially when it comes to white box testing) which are well documented, e.g.
[https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html]
Various approaches are discussed in above mentioned document, including using options --patch-module, opening modules etc.
In some cases this may be overkill and it also requires additional configuration that may be repeated over time (e.g. after adding new packages)
Another approach mentioned in the document is strikingly simple:
{panel:title=Resort to the classpath}
Delete all {{module-info.java}} files, or exclude them from compilation, and your tests ignore all boundaries implied by the Java module system. Use internal implementation details of the Java runtime, 3rd-party libraries including test framework and of course, use the internal types from your _main_ source set. The last part was the intended goal - achieved, yes, but paid a very high price.
{panel}
Obviously there is a price, e.g. not enforcing the boundaries JPMS provides (e.g. on usage of reflection).
But it is a very effective approach.
*Feature request*
Add new option to maven compiler plugin to ignore "module-info.java" files during compilation.
For example, apply new option in CompilerMojo.java ([https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java)] and set hasModuleDescriptor to "false" in preparePaths method.
was:
Running unit test cases in modularized java projects has its own challenges (especially when it comes to white box testing) which are well documented, e.g.
[https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html]
Various approaches are discussed in above mentioned document, including using options --patch-module, opening modules etc.
In some cases this may be overkill and it also requires additional configuration.
Another approach mentioned in the document is strikingly simple:
{panel:title=Resort to the classpath}
Delete all {{module-info.java}} files, or exclude them from compilation, and your tests ignore all boundaries implied by the Java module system. Use internal implementation details of the Java runtime, 3rd-party libraries including test framework and of course, use the internal types from your _main_ source set. The last part was the intended goal - achieved, yes, but paid a very high price.
{panel}
Obviously there is a price, e.g. not enforcing the boundaries JPMS provides (e.g. on usage of reflection).
But it is a very effective approach.
*Feature request*
Add new option to maven compiler plugin to ignore "module-info.java" files during compilation.
For example, apply new option in CompilerMojo.java ([https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java)] and set hasModuleDescriptor to "false" in preparePaths method.
> Ignore module-info.java
> -----------------------
>
> Key: MCOMPILER-393
> URL: https://issues.apache.org/jira/browse/MCOMPILER-393
> Project: Maven Compiler Plugin
> Issue Type: New Feature
> Affects Versions: 3.8.1
> Reporter: Holger Haag
> Priority: Minor
>
> Running unit test cases in modularized java projects has its own challenges (especially when it comes to white box testing) which are well documented, e.g.
> [https://sormuras.github.io/blog/2018-09-11-testing-in-the-modular-world.html]
> Various approaches are discussed in above mentioned document, including using options --patch-module, opening modules etc.
> In some cases this may be overkill and it also requires additional configuration that may be repeated over time (e.g. after adding new packages)
> Another approach mentioned in the document is strikingly simple:
>
>
> {panel:title=Resort to the classpath}
> Delete all {{module-info.java}} files, or exclude them from compilation, and your tests ignore all boundaries implied by the Java module system. Use internal implementation details of the Java runtime, 3rd-party libraries including test framework and of course, use the internal types from your _main_ source set. The last part was the intended goal - achieved, yes, but paid a very high price.
> {panel}
> Obviously there is a price, e.g. not enforcing the boundaries JPMS provides (e.g. on usage of reflection).
>
> But it is a very effective approach.
>
> *Feature request*
>
> Add new option to maven compiler plugin to ignore "module-info.java" files during compilation.
>
> For example, apply new option in CompilerMojo.java ([https://github.com/apache/maven-compiler-plugin/blob/master/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java)] and set hasModuleDescriptor to "false" in preparePaths method.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)