-
Notifications
You must be signed in to change notification settings - Fork 172
compiler plugin does not process JPMS patch modules correctly #321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The compiler plugin got a major refactoring in Maven 4, especially regarding JPMS. Would you have the possibility to test with Maven 4.0.0-rc-3 and the compiler plugin 4.0.0-beta-3-SNAPSHOT? Unfortunately, it would require to build the compiler plugin locally, preferably from the pull request #320. |
@desruisseaux I will attempt today and report back here, thx for your rapid response!!! watch this space... |
@desruisseaux downloaded 4.0.0-rc3, installed, cloned maven-compiler-plugin and pulled PR #320 built and installed in my local m2 repo and attempted to rebuild my patch module project... sadly the same results occur, compiler appears (my intuition) to no longer be resolving (java) dependencies against the pre-existing model that is the target of the --patch-module option... direct invocation of javac (24) with --patch-module compiles cleanly to further refine the failure mode, the packages that are not found during compilation are not exported from the target module... it appears to me as if somehow the behavior of the plugin w.r.t --patch-modules differs from that of javac; whereas javac when compiling the patch sources it will successfully satisfy references within the patch sources to pre-existing artifacts in the this renders the compiler plugin somewhat unusable for the purposes of compiling patch modules... and is not implementing note:
|
When the compilation fails, a |
yes ... :( |
the mystery deepens, so I strace(1) mvn and located the execve of javac:
I extracted this and created a a shell file and experimented with this to determine what was the difference between this and you will be glad to hear that it does not appear to be a plugin bug but in fact the presence of a --release option that appears I'll ask internally why this is so ... @desruisseaux many thanks for your help today! very very much appreciated! |
Thanks for the investigation, and thanks for testing the plugin snapshot as well. Should we close this issue? |
tested with 3.9.9 and 3.14.0 with it compiles cleanly. I believe the underlying issue is the interaction between --release and --plugin-module in the javac compiler. while --plugin-module compiles the target sources as if they are in the scope of the target module, --release effectively overrides this and enforces module public access only, hence the compile errors reported against non-public dependencies thanks again for your assistance! |
Affected version
3.5.9
Bug description
the java module system supports the ability to compile and execute "patch modules" these are patches to existing modules that override pre-existing content with replacements.
in order to compile (patch) classes for inclusion as a "patch module" the
javac
compiler supports a cmdline option:--patch-module <module-name>=<path-to-module-source-root>
invoking
javac
directly with the--patch-module...
option specified works as intended, however when attempting to use the maven plugin compiler with:<compilerArgs> <arg>--patch-module</arg> <arg>java.base=${project.basedir}/...</arg> </compilerArgs>
specifying the same '' as with the invocation of
javac
the plugin fails to compile the patch classes.the failures reported suggest that the compiler is failing to resolve dependencies expressed in the sources of the patch classes against the target module being patched...
e.g:
I have a module that contains a number of classes and packages, and I wish to patch an existing class therein
so I create a "patch" class in tne maven project.
such a class may of course refer to other classes that already exist in the module to be patch, but those dependencies are not patched themselves.
the patched class compilation will fail (when compiled by the plugin) with errors naming any references to
dependencies in the target module as non-existent
The text was updated successfully, but these errors were encountered: