[
https://issues.apache.org/jira/browse/MCOMPILER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17289490#comment-17289490
]
Claudio Corsi commented on MCOMPILER-447:
-----------------------------------------
[~bmarwell]
No worries, I looked at the aforementioned link and gave it a try. I was able
to use that technique but it seems wrong that someone would have to go through
all of that trouble to create a multi-version jar file. Especially one that is
a combination like the one that I am trying to create/use. The first part of
this first will remove the need to add such a configuration within the pom
file. It would make the pom file cleaner and more like what is expected.
As for a use-case, you can take the added pom file that is part of the
MCOMPLIER-447 integration test. To reproduce this case, you only would need to
use the compile-java-9 and test-compile-java-9 executions at:
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L57
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/pom.xml#L83
To not reproduce the other issue mentioned in this issue. You need to comment
out the Logger.getLogger call within the Test.java file at
https://github.com/apache/maven-compiler-plugin/blob/064b889c1dbc237081a54aceae4560d8942308f5/src/it/MCOMPILER-447/src/test/test9/org/bar/Test.java#L29
On Monday, December 21, 2020, 5:10:01 PM EST, Benjamin Marwell (Jira)
<j...@apache.org> wrote:
[
https://issues.apache.org/jira/browse/MCOMPILER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17253146#comment-17253146
]
Benjamin Marwell commented on MCOMPILER-447:
--------------------------------------------
[~ccorsi]
Sorry that I just know realized what you actually meant in this issue:
{quote}The following changes resolves two different issues. The first is the
case that
the we are creating a multi-version jar file that by default is not modularized.
{quote}
There is no need to do such a thing. A
{color:#0747a6}{{module-info.class}}{color} in the root folder will be ignored
by Java 7 and Java 8. See the [second example
here|https://maven.apache.org/plugins/maven-compiler-plugin/examples/module-info.html].
{quote}a multi-version jar file that by default is not modularized.
{quote}
What is the use case here?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
> Unable to compile modularized test for a multi-version jar that is not a java
> module by default
> -----------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-447
> URL: https://issues.apache.org/jira/browse/MCOMPILER-447
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Affects Versions: 3.8.1
> Reporter: Claudio Corsi
> Priority: Blocker
>
> I have a single module project that is creating a mult-version jar file. By
> default the multi-version jar is not a java module because it is being built
> for jdk 7 or newer. The multi-version jar does contain a java module
> definition within the /META-INF/versions/9 directory. I am trying to create
> a integration test that uses the java module of the code. When I tried
> building the module tests I got the UnsupportedOperationException with the
> message:
>
> Can't compile test sources when main sources are missing a module descriptor
>
> The issue was that the main module does not contain a module descriptor but
> the test does contain a module descriptor.
>
> I then forked a copy of the maven compiler plugin. I created an integration
> test and was able to fix this issue. The issue was that I needed to find the
> latest version of the java-module for the module generated multi-version jar
> file. This because the module descriptor and was added to the javac command.
>
> I then tried to build my test source again and this time it stated that it
> was not able to find a class because it is part of a jar file that does not
> contain any java module definition. I updated the integration test and was
> able to add another fix to the forked copy that resolved that issue. The
> issue was that all non-java-module jar files should be included as part of
> the class path. They were all being included as part of the module path.
>
> I then used the fixed jar file to build my project and it failed again
> because of it accessing a unnamed module. I had to finally update my pom to
> include a --add-reads command line option. I will not try to add a fix to
> this issue since this issue has a workaround unlike the other two that didn't.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
