You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "foo bar (JIRA)" <ji...@apache.org> on 2018/07/29 19:22:00 UTC

[jira] [Comment Edited] (MCOMPILER-354) Module patching fails: case of simple single-module project

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

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

It's not a normal setup because it's a minimization branch. You can see a less minimized project structure including tests (but still single-module) here:
{code:java}
git checkout a288b4cd4ce67308ffd3a768f3a4a25efc31cf6a
{code}

I do verify that it compiles if i make DoesntCompile::f package-private (even though I don't understand why). 
In a288b4cd4ce67308ffd3a768f3a4a25efc31cf6a the same change(making the test methods in Accumulable_PbtTest package-private) compiles too! But that's not a solution, since the test methods need to be public:
{code:java}
[INFO] --- maven-surefire-plugin:2.22.0:test (default-test) @ wires-support ---
[WARNING] useSystemClassloader setting has no effect when not forking
[INFO] Running fr.cla.wires.support.oo.Accumulable_PbtTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.044 s <<< FAILURE! - in fr.cla.wires.support.oo.Accumulable_PbtTest
[ERROR] initializationError(fr.cla.wires.support.oo.Accumulable_PbtTest)  Time elapsed: 0.002 s  <<< ERROR!
java.lang.Exception: Method if_newVal_is_not_null_mutableEquivalentToInitially_should_be_equivalent_to_initially() should be public
{code}

About Java "protecting me from creating unusable classes", I don't see what you mean at all: 
* What  do you mean "all exported classes must be usable"? Can you point me to some spec/definition? I thought that to be visible from another module a class had to be both public and in an exported package. So can I not have package-private classes in exported modules?
* Same for "Java sees them as sharable module" I don't see what you mean in terms of requires/exports/opens. Or is that about the unnamed module/automatic modules? 
* Finally I don't see why a class should be exported to the same module. Or is that again about the unnamed module/automatic modules? 
* Is what you're saying specific to patching or is that a general rule? Does the nature of a module change when it's patched?


was (Author: vandekeizer):
It's not a normal setup because it's a minimization branch. You can see a less minimized project structure including tests (but still single-module) here:
{code:java}
git checkout a288b4cd4ce67308ffd3a768f3a4a25efc31cf6a
{code}

I do verify that it compiles if i make DoesntCompile::f package-private (even though I don't understand why). 
But if try that in a288b4cd4ce67308ffd3a768f3a4a25efc31cf6a, that's not a solution, since the test methods need to be public:
{code:java}
[INFO] --- maven-surefire-plugin:2.22.0:test (default-test) @ wires-support ---
[WARNING] useSystemClassloader setting has no effect when not forking
[INFO] Running fr.cla.wires.support.oo.Accumulable_PbtTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.044 s <<< FAILURE! - in fr.cla.wires.support.oo.Accumulable_PbtTest
[ERROR] initializationError(fr.cla.wires.support.oo.Accumulable_PbtTest)  Time elapsed: 0.002 s  <<< ERROR!
java.lang.Exception: Method if_newVal_is_not_null_mutableEquivalentToInitially_should_be_equivalent_to_initially() should be public
{code}

About Java "protecting me from creating unusable classes", I don't see what you mean at all: 
* What  do you mean "all exported classes must be usable"? Can you point me to some spec/definition? I thought that to be visible from another module a class had to be both public and in an exported package. So can I not have package-private classes in exported modules?
* Same for "Java sees them as sharable module" I don't see what you mean in terms of requires/exports/opens. Or is that about the unnamed module/automatic modules? 
* Finally I don't see why a class should be exported to the same module. Or is that again about the unnamed module/automatic modules? 
* Is what you're saying specific to patching or is that a general rule? Does the nature of a module change when it's patched?

> 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)