[
https://issues.apache.org/jira/browse/MCOMPILER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anand Beh updated MCOMPILER-462:
--------------------------------
Description:
Building a project with a module descriptor placed in a multi-release
directory, and in conjunction with the maven-bundle-plugin, creates
discrepancies between "clean package" and "package" after changes have been
made to the source tree.
This is best explained by reproducing the issue.
*Reproducer*
Attached to this issue. Also clonable from
[https://github.com/A248/ModularMRJAR]
*Steps to reproduce*
# Download the attached reproducer
# *First Run:* Run _mvn package_
# Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
# *Second Run*: Run _mvn package_
# *Third Run*: Run _mvn clean package_
The Second Run can be repeated any number of times. It will consistently fail
with the reason that the org.mrjar package is not found.
*Results*
* First Run - compilation success
* Second Run - failure
* Third Run - success
The Third Run and the Second Run should compile identically.
*Analysis*
The difference between the second run and the third run is visible using the -X
option.
The trouble happens when compiling the MR classes - i.e., the compile-java11
execution defined in the reproducer's pom.
On the second run, the non-MR classes are placed on the modulepath. The MR
classes fail to compile:
{code:java}
[DEBUG] Classpath:
[DEBUG] Modulepath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
--module-path /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --module-version 0.1.0-SNAPSHOT{code}
On the third run, the non-MR classes are placed on the classpath. The MR
classes compile. It is further notable that the compiler command line options
differ:
{code:java}
[DEBUG] Classpath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
-classpath /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --patch-module
org.mrjar=/Users/anandbeh/git/ModularMRJAR/target/classes --module-version
0.1.0-SNAPSHOT{code}
*How to Resolve / Lesson from when not using the maven-bundle-plugin*
If the maven-bundle-plugin were to _NOT_ be used, then:
# The Second Run would succeed.
# The non-MR classes are placed on the class-path consistently.
This suggests the behavior of the Second Run in placing the non-MR classes on
the module-path is incorrect. The Second Run should place the non-MR classes on
the class-path just like the Third Run does.
was:
Building a project with a module descriptor placed in a multi-release
directory, and in conjunction with the maven-bundle-plugin, creates
discrepancies between "clean package" and "package" after changes have been
made to the source tree.
This is best explained by reproducing the issue.
*Reproducer*
Attached to this issue. Also clonable from
[https://github.com/A248/ModularMRJAR]
*Steps to reproduce*
# Download the attached reproducer
# *First Run:* Run _mvn package_
# Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
# *Second Run*: Run _mvn package_
# *Third Run*: Run _mvn clean package_
The Second Run can be repeated any number of times. It will consistently fail
with the reason that the org.mrjar package is not found.
*Results*
* First Run - compilation success
* Second Run - failure
* Third Run - success
The Third Run and the Second Run should compile identically.
*Analysis*
The difference between the second run and the third run is visible using the -X
option.
The trouble happens when compiling the MR classes - i.e., the compile-java11
execution defined in the reproducer's pom.
On the second run, the non-MR classes are placed on the modulepath. The MR
classes fail to compile:
{code:java}
[DEBUG] Classpath:
[DEBUG] Modulepath:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
--module-path /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
-s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
-nowarn --release 11 -encoding UTF-8 --module-version 0.1.0-SNAPSHOT{code}
On the third run, the non-MR classes are placed on the classpath. The MR
classes compile. It is further notable that the compiler command line options
differ:
{code:java}
[DEBUG] Classpath:
[DEBUG] /Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes
[DEBUG] Source roots:
[DEBUG] /Users/anandbeh/git/SolarMC/ModularMRJAR/src/main/java11
[DEBUG] Command line options:
[DEBUG] -d
/Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes/META-INF/versions/11
-classpath /Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes: -sourcepath
/Users/anandbeh/git/SolarMC/ModularMRJAR/src/main/java11:/Users/anandbeh/git/SolarMC/ModularMRJAR/target/generated-sources/annotations:
-s
/Users/anandbeh/git/SolarMC/ModularMRJAR/target/generated-sources/annotations
-g -nowarn --release 11 -encoding UTF-8 --patch-module
org.mrjar=/Users/anandbeh/git/SolarMC/ModularMRJAR/target/classes
--module-version 0.1.0-SNAPSHOT{code}
*How to Resolve / Lesson from when not using the maven-bundle-plugin*
If the maven-bundle-plugin were to _NOT_ be used, then:
# The Second Run would succeed.
# The non-MR classes are placed on the class-path consistently.
This suggests the behavior of the Second Run in placing the non-MR classes on
the module-path is incorrect. The Second Run should place the non-MR classes on
the class-path just like the Third Run does.
> Modular Multi-Release JAR and Maven-Bundle-Plugin together cause inconsistent
> compilation behavior
> --------------------------------------------------------------------------------------------------
>
> Key: MCOMPILER-462
> URL: https://issues.apache.org/jira/browse/MCOMPILER-462
> Project: Maven Compiler Plugin
> Issue Type: Bug
> Affects Versions: 3.8.1
> Environment: Mac OS 10.14.6
> Maven 3.8.1
> Maven-Compiler-Plugin 3.8.1
> Maven-Bundle-Plugin 5.1.2
> Reporter: Anand Beh
> Priority: Major
> Attachments: ModularMRJAR.zip
>
>
> Building a project with a module descriptor placed in a multi-release
> directory, and in conjunction with the maven-bundle-plugin, creates
> discrepancies between "clean package" and "package" after changes have been
> made to the source tree.
> This is best explained by reproducing the issue.
> *Reproducer*
> Attached to this issue. Also clonable from
> [https://github.com/A248/ModularMRJAR]
> *Steps to reproduce*
> # Download the attached reproducer
> # *First Run:* Run _mvn package_
> # Add a new class, e.g. "Clazz2" in src/main/java/org/mrjar
> # *Second Run*: Run _mvn package_
> # *Third Run*: Run _mvn clean package_
> The Second Run can be repeated any number of times. It will consistently fail
> with the reason that the org.mrjar package is not found.
> *Results*
>
> * First Run - compilation success
> * Second Run - failure
> * Third Run - success
> The Third Run and the Second Run should compile identically.
> *Analysis*
> The difference between the second run and the third run is visible using the
> -X option.
> The trouble happens when compiling the MR classes - i.e., the compile-java11
> execution defined in the reproducer's pom.
> On the second run, the non-MR classes are placed on the modulepath. The MR
> classes fail to compile:
> {code:java}
> [DEBUG] Classpath:
> [DEBUG] Modulepath:
> [DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
> [DEBUG] Source roots:
> [DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
> [DEBUG] Command line options:
> [DEBUG] -d
> /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
> --module-path /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
> /Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
> -s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
> -nowarn --release 11 -encoding UTF-8 --module-version 0.1.0-SNAPSHOT{code}
> On the third run, the non-MR classes are placed on the classpath. The MR
> classes compile. It is further notable that the compiler command line options
> differ:
>
> {code:java}
> [DEBUG] Classpath:
> [DEBUG] /Users/anandbeh/git/ModularMRJAR/target/classes
> [DEBUG] Source roots:
> [DEBUG] /Users/anandbeh/git/ModularMRJAR/src/main/java11
> [DEBUG] Command line options:
> [DEBUG] -d
> /Users/anandbeh/git/ModularMRJAR/target/classes/META-INF/versions/11
> -classpath /Users/anandbeh/git/ModularMRJAR/target/classes: -sourcepath
> /Users/anandbeh/git/ModularMRJAR/src/main/java11:/Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations:
> -s /Users/anandbeh/git/ModularMRJAR/target/generated-sources/annotations -g
> -nowarn --release 11 -encoding UTF-8 --patch-module
> org.mrjar=/Users/anandbeh/git/ModularMRJAR/target/classes --module-version
> 0.1.0-SNAPSHOT{code}
>
> *How to Resolve / Lesson from when not using the maven-bundle-plugin*
> If the maven-bundle-plugin were to _NOT_ be used, then:
> # The Second Run would succeed.
> # The non-MR classes are placed on the class-path consistently.
> This suggests the behavior of the Second Run in placing the non-MR classes on
> the module-path is incorrect. The Second Run should place the non-MR classes
> on the class-path just like the Third Run does.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
