maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "foo bar (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (MCOMPILER-354) Module patching fails: case of simple single-module project
Date Sun, 29 Jul 2018 21:10:00 GMT

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

foo bar edited comment on MCOMPILER-354 at 7/29/18 9:09 PM:
------------------------------------------------------------

Mhhhh! I think I get it (but this still seems problematic to me: sounds like test-scoped dependencies
and whitebox tests can't work together):
* {{DoesntCompile}} is in an exported package
* It's method signature references a type of a non-exported package
* So javac warns me that it in unusable by any client
* {{Compiles}} compiles because it is not in an exported package so no such check is done.




So let me see the implications of this. 
Given a test {{T}} of a class {{C}}, if the following are both true:
* {{T}} is in the same package as {{C}} (this is the case of whitebox tests - tests which
exercise package-private classes and methods)
* {{C}} is in an exported package

Then to avoid the warning:
* {{T}} must only "visibly reference" classes of exported packages (eg. a public/protected
method argument or return type constitutes a visible reference, while a private/package-private
does not).

Indeed, if I ignore the warning, the support module compiles and runs, but the client module
doesn't compile since the test class in support is not visible.


To sum it up the following circumstances can't work:
a/ modules {{lib}} and {{client}} are 2 maven and jigsaw modules. {{client}} depends on {{lib}}
b/ class {{Clib}} in {{src/main}} of {{lib}} is in an exported package
c/ class {{Tlib}} in {{src/test}} of {{lib}} is in the same package as {{Clib}} (eg. because
it's a whitebox test who wants to test the package-private methods of {{Clib}}) 
d/ {{Tlib}} references a class {{Tlibunex}} of an unexported package (ex: a test support class)
"in a visible way" (ex: as argument of a public method)
e/ {{Tclient}} in {{src/test}} of {{client}} depends on {{Tlib}} 

--> Step e/ generates a compile error because {{Tlib}} references unexported {{Tlibunex}}
(javac just says it can't find {{Tlib}})
Makes sense, since: 
* We want to run the test with the module system, just like in production
* Test classes patched into the module are indistinguishable from the main classes.

*But 
I have no way to export {{Tlibunex}} since it is in {{src/test}}, and therefore not visible
from {{module-info.java}} (it doesn't compile if I try to export it) !
So doesn't that mean that test-scoped dependencies and whitebox tests can't work together?
*



was (Author: vandekeizer):
Mhhhh! I think I get it (but this still seems problematic to me: sounds like test-scoped dependencies
and whitebox tests can't work together):
* {{DoesntCompile}} is in an exported package
* It's method signature references a type of a non-exported package
* So javac warns me that it in unusable by any client
* {{Compiles}} compiles because it is not in an exported package so no such check is done.


So let me see the implications of this. 
Given a test {{T}} of a class {{C}}, if the following are both true:
* {{T}} is in the same package as {{C}} (this is the case of whitebox tests - tests which
exercise package-private classes and methods)
* {{C}} is in an exported package

Then to avoid the warning:
* {{T}} must only "visibly reference" classes of exported packages (eg. a public/protected
method argument or return type constitutes a visible reference, while a private/package-private
does not).

Indeed, if I ignore the warning, the support module compiles and runs, but the client module
doesn't compile since the test class in support is not visible.


To sum it up the following circumstances can't work:
a/ modules {{lib}} and {{client}} are 2 maven and jigsaw modules. {{client}} depends on {{lib}}
b/ class {{Clib}} in {{src/main}} of {{lib}} is in an exported package
c/ class {{Tlib}} in {{src/test}} of {{lib}} is in the same package as {{Clib}} (eg. because
it's a whitebox test who wants to test the package-private methods of {{Clib}}) 
d/ {{Tlib}} references a class {{Tlibunex}} of an unexported package (ex: a test support class)
"in a visible way" (ex: as argument of a public method)
e/ {{Tclient}} in {{src/test}} of {{client}} depends on {{Tlib}} 

--> Step e/ generates a compile error because {{Tlib}} references unexported {{Tlibunex}}
(javac just says it can't find {{Tlib}})
Makes sense, since: 
-We want to run the test with the module system, just like in production
-Test classes patched into the module are indistinguishable from the main classes.

*But 
I have no way to export {{Tlibunex}} since it is in {{src/test}}, and therefore not visible
from {{module-info.java}} (it doesn't compile if I try to export it) !
So doesn't that mean that test-scoped dependencies and whitebox tests can't work together?
*


> Module patching fails: case of simple single-module project
> -----------------------------------------------------------
>
>                 Key: MCOMPILER-354
>                 URL: https://issues.apache.org/jira/browse/MCOMPILER-354
>             Project: Maven Compiler Plugin
>          Issue Type: Bug
>    Affects Versions: 3.7.0
>         Environment: $ mvn -version
> Apache Maven 3.5.4 (1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T20:33:14+02:00)
> Maven home: G:\software\apache-maven-3.5.4-bin\apache-maven-3.5.4
> Java version: 10.0.2, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk-10.0.2
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>            Reporter: foo bar
>            Priority: Major
>              Labels: Jigsaw
>         Attachments: mvn-X-clean-install-FAILURE.log, project.png, wires.zip
>
>
> Sometimes it can be difficult to setup maven test-scoped dependencies in a Maven multi-module
project. But I think I managed to find a simple 1-module case where module patching doesn't
work.
> I have a single-module Java 10 project where the testCompile goal complains that Test
Class A doesn't read Test Class B, which is in the same project! (but in a different package)
> Of course, a class shouldn't need to be exported to a class of the same module. So maybe
there is a confusion somewhere between the unnamed module, automatic modules, and explicit
modules.
> I think that's because of a bug in the module-patching flags passed by testCompile to
javac.
> My project source tree, in its simplified branch to reproduce the issue, looks shown
in the project.png attachment.
> Full log is attached as well as a zip of the issue reproduction branch. It can also be
cloned from: 
> {code:java}
> git clone https://github.com/vandekeiser/wires.git
> git checkout REPORT-MCOMPILER-2
> mvn clean install
> {code}
> The flags testCompile pass to javac.
> {code:java}
> [INFO] --- maven-compiler-plugin:3.7.0:testCompile (default-testCompile) @ wires-support
---
> [DEBUG] Command line options:
>     -d G:\projets\wires\wires\wires\wires-support\target\test-classes
>     -classpath G:\projets\wires\wires\wires\wires-support\target\test-classes;
>     --module-path G:\projets\wires\wires\wires\wires-support\target\classes;
>     -sourcepath G:\projets\wires\wires\wires\wires-support\src\test\java;
>                 G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations;
>     -s G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations
>     -g -deprecation -target 10 -source 10 -encoding UTF-8 -Werror -Xlint:all,-serial
>     --patch-module fr.cla.wires.support=
>         G:\projets\wires\wires\wires\wires-support\target\classes;
>         G:\projets\wires\wires\wires\wires-support\src\test\java;
>         G:\projets\wires\wires\wires\wires-support\target\generated-test-sources\test-annotations;
>     --add-reads fr.cla.wires.support=ALL-UNNAMED
> {code}
> The warning I get (which for me is an error):
> {code:java}
> [WARNING] /G:/projets/wires/wires/wires/wires-support/src/test/java/fr/cla/wires/support/DoesntCompile.java:[14,20]
>     class fr.cla.wires.support.javac_complains_this_is_not_exported.JavacComplainsThisIsNotExported
>     in module fr.cla.wires.support
>     is not exported
> [ERROR] COMPILATION ERROR :
> warnings found and -Werror specified
> [INFO] 1 error
> {code}



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

Mime
View raw message