[jira] [Comment Edited] (MCOMPILER-393) Ignore module-info.java

["Holger Haag (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MCOMPILER-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16879825#comment-16879825 ] 

Holger Haag edited comment on MCOMPILER-393 at 7/7/19 10:10 AM:
----------------------------------------------------------------

Robert, it does!

{code:java}
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
{code}

Thanks for the help and quick reply :)

Shall I close the issue or what's the right workflow?

BR,
Holger


was (Author: hhaag):
Robert, it does!

{code:java}
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 9, Failures: 0, Errors: 0, Skipped: 0
{code}

Thanks for the help and quick reply :)

Shall I just close the issue?

BR,
Holger

> 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.
>  
> *Additional uses of new option*
> Ressource filtering does not work on module-info.java since code is hard-wired to read it. Therfore it is not possible with standard maven configuration to compile on class path instead of module path if it is desired (e.g. during migration period from classpath to modulepath).
>  
> *Contribution*
> I'd be happy to contribute (or find somebody to do so).
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)