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