[MCOMPILER-372] - fix test compile issue: added dependency test path for modules #27

floison51 · 2019-12-17T13:27:10Z

Following this checklist to help us incorporate your
contribution quickly and easily:

Make sure there is a JIRA issue filed
for the change (usually before you start working on it). Trivial changes like typos do not
require a JIRA issue. Your pull request should address just this issue, without
pulling in other changes.
Each commit in the pull request should have a meaningful subject line and body.
Format the pull request title like [MPH-XXX] - Fixes bug in ApproximateQuantiles,
where you replace MPH-XXX with the appropriate JIRA issue. Best practice
is to use the JIRA issue title in the pull request title and in the first line of the
commit message.
Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
Run mvn clean verify to make sure basic checks pass. A more thorough check will
be performed on your pull request automatically.
You have run the integration tests successfully (mvn -Prun-its clean verify).

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004
In any other case, please file an Apache Individual Contributor License Agreement.

compiler argument

…ugin.git

floison51 · 2019-12-17T13:30:57Z

I added an integration test case reproducing MCOMPILER-372 test case.
Bug root case: project2 depends on project1. Both are modularized. Test compilation of project2 fails because project2 test can acceed to project 1 module but not to project 1 test class patch (i.e. project1/target/test-classes).
When this configuration is detected, project 1 test class path is added as -patchModule compiler options. All integration tests pass.

generation

module

(when existing) For each module : --add-reads <module name>=ALL-UNNAMED given access to classes from unnamed modules (for example JUnit classes)

…ugin.git

rfscholte · 2020-01-03T20:13:40Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+     * @param modulePathElt
+     * @return
+     */
+    private File getModuleTestPathElt( File modulePathElt )


This methods feels a bit like best guessing. It is better to loop over all the reactorProjects to find the Paths that belong to the same Maven Project (and because of that to the same module)

floison51 · 2020-01-06T20:03:29Z

OK, on going. Le ven. 3 janv. 2020 à 21:13, Robert Scholte <notifications@github.com> a écrit :

…

***@***.**** commented on this pull request. ------------------------------ In src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java <#27 (comment)> : > } } } + /** + * Get module test path element from module path element + * @param modulePathElt + * @return + */ + private File getModuleTestPathElt( File modulePathElt ) This methods feels a bit like best guessing. It is better to loop over all the reactorProjects to find the Paths that belong to the same Maven Project (and because of that to the same module) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=AEKICU6WINGDTYY24MQIFSTQ36L7LA5CNFSM4J33NR7KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQUVZPQ#pullrequestreview-338255038>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKICU7SGD5HUI6VWYOCDADQ36L7LANCNFSM4J33NR7A> .

path element, if it does not succeed, guess test path element from path element

floison51 · 2020-01-07T09:54:05Z

Change is commited. Best regards, François Le lun. 6 janv. 2020 à 21:03, François Loison <francois.loison.51@gmail.com> a écrit :

…

OK, on going. Le ven. 3 janv. 2020 à 21:13, Robert Scholte ***@***.***> a écrit : > ***@***.**** commented on this pull request. > ------------------------------ > > In src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java > <#27 (comment)> > : > > > } > } > } > > + /** > + * Get module test path element from module path element > + * @param modulePathElt > + * @return > + */ > + private File getModuleTestPathElt( File modulePathElt ) > > This methods feels a bit like best guessing. It is better to loop over > all the reactorProjects to find the Paths that belong to the same Maven > Project (and because of that to the same module) > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#27?email_source=notifications&email_token=AEKICU6WINGDTYY24MQIFSTQ36L7LA5CNFSM4J33NR7KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQUVZPQ#pullrequestreview-338255038>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEKICU7SGD5HUI6VWYOCDADQ36L7LANCNFSM4J33NR7A> > . >

rfscholte · 2020-01-07T18:05:32Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+    {
+
+        // Get test path from reactor projects
+        File result = getModuleTestPathEltFromReactorProjects( modulePathElt );


Can you change this to return getModuleTestPathEltFromReactorProjects( modulePathElt );

I can't think of a reason why we need the rest of the code in this method. It would mean something went wrong somewhere else.

floison51 · 2020-01-08T08:04:05Z

Hello, I added this "second chance" test arefact resolution for following reason: project may have a test dependency to a test artifact wich is not in reactor projects list. For better explanation, I did the modification you suggested and built then compiler plugin. In target/it/MCOMPILER-372_modularized_testjar, there are at least 2 projects: -> prj1 : defining prj1-tests.jar containing a Prj1Test class -> prj2 : test dependency to prj1, containing Prj2Test class extending Prj1Test Integration test is OK. If I run clean install from * target/it/MCOMPILER-372_modularized_testjar *folder, there is a problem. mvn clean install [ERROR] COMPILATION ERROR : [INFO] ------------------------------------------------------------- [ERROR] /C:/Users/frup82455/git/loizbak/maven-compiler-plugin/target/it/MCOMPILER-372_modularized_testjar/prj2/src/test/java/prj2/Prj2Test.java:[25,12] cannot f ind symbol symbol: class Prj1Test location: package prj1 [ERROR] /C:/Users/frup82455/git/loizbak/maven-compiler-plugin/target/it/MCOMPILER-372_modularized_testjar/prj2/src/test/java/prj2/Prj2Test.java:[27,31] cannot f ind symbol symbol: class Prj1Test [INFO] 2 errors [INFO] ------------------------------------------------------------- [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary for mcompiler-372 1.0-SNAPSHOT: [INFO] [INFO] mcompiler-372 ...................................... SUCCESS [ 0.374 s] [INFO] prj0-372 ........................................... SUCCESS [ 19.295 s] [INFO] prj1-372 ........................................... SUCCESS [ 2.031 s] [INFO] prj2-372 ........................................... FAILURE [ 53.307 s] [INFO] prj3-372 ........................................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ It fails because getModuleTestPathElt() tries to find sibling test artefact of C:\...\maven-compiler-plugin\target\it\MCOMPILER-372_modularized_testjar\prj1\target\ *prj1-372-1.0-SNAPSHOT.jar*. Reactor project build directory is C:\...\maven-compiler-plugin\target\it\MCOMPILER-372_modularized_testjar\prj1\target\ *classes* So method getModuleTestPathEltFromReactorProjects() doesn't match target\ *prj1-372-1.0-SNAPSHOT.jar* and target\*classes*. No test artefact is provided back and test compilation fails. I reactivated the "double chance" method and it works fine: Reactor Summary for mcompiler-372 1.0-SNAPSHOT: mcompiler-372 ...................................... SUCCESS [ 0.577 s] prj0-372 ........................................... SUCCESS [ 8.593 s] prj1-372 ........................................... SUCCESS [ 5.870 s] prj2-372 ........................................... SUCCESS [ 6.139 s] prj3-372 ........................................... SUCCESS [ 6.727 s] ------------------------------------------------------------------------ BUILD SUCCESS ------------------------------------------------------------------------ It's strange that integration doesn't excercize this test case the same as from the command prompt. I would appreciate suggestions to improve that integration test, may be 2 test artifacts resolution flavours : one with prj1\target\*classes *and one with prj1\target\*prj1-372-1.0-SNAPSHOT.jar* Anyway, there are other case where resolution from reactor projets list wouldn't work. Assume prj2 is build from a standalone folder, prj1 would not be in reactor list. In other work, I can't figure out how to get rid of "double chance" test artefact resolution. Best regards, François Le mar. 7 janv. 2020 à 19:05, Robert Scholte <notifications@github.com> a écrit :

…

***@***.**** commented on this pull request. ------------------------------ In src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java <#27 (comment)> : > + { + pathElements.put( entry.getKey().getAbsolutePath(), entry.getValue() ); + } + } + } + + /** + * Get module test path element from module path element + * @param modulePathElt + * @return + */ + private File getModuleTestPathElt( File modulePathElt ) + { + + // Get test path from reactor projects + File result = getModuleTestPathEltFromReactorProjects( modulePathElt ); Can you change this to return getModuleTestPathEltFromReactorProjects( modulePathElt ); I can't think of a reason why we need the rest of the code in this method. It would mean something went wrong somewhere else. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=AEKICUZCIALIZ4EDDAUUAIDQ4S763A5CNFSM4J33NR7KYY3PNVWWK3TUL52HS4DFWFIHK3DMKJSXC5LFON2FEZLWNFSXPKTDN5WW2ZLOORPWSZGOCQ5PQPA#pullrequestreview-339408956>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKICU3VT4DVWVRURRAU6JTQ4S763ANCNFSM4J33NR7A> .

Prj2 was not uploading test jar to local repo. Prj2 was not opening prj2 package.

rfscholte · 2020-01-08T19:04:23Z

If you only need the reactor, please never use install anymore, but just verify. And with this plugin you should only use compile, test-compile or package (in case you depend on the jar).
I wonder if we should allow pulling in test-jars from outside the reactor. I know it is possible, but it is a codesmell to me, especially in the JPMS world. (and if overcomplicates the code)

floison51 · 2020-01-09T18:15:31Z

OK, I understand why you were reluctant to adress tests jars from repository. *Back to the root cause of the problem:* The simplest solution would be to setup 2 module-info.java : one for artefact, one for test artefact (with a different module name). But IDEs like Eclipse don't support 2 java files with same name, only the main module-info.java is created. Unfortunately, this solution has side-effects on test artefacts inheritancy. If "double chance" solution (guess test artifact names) is not accepted, I don't see possibility of a fix given the single module-info.java assumption. Moreover, surefire plugin 3.0.0-SNAPSHOT has same problem. So I which modify my code to put test inheritancy in main modules. This is not recommended because it adds test dependencies to main module (I will have to filter them from final package). I will also release the pull request without the "double chance" solution. Best regards, François Le mer. 8 janv. 2020 à 20:04, Robert Scholte <notifications@github.com> a écrit :

…

If you only need the reactor, please never use install anymore, but just verify. And with this plugin you should only use compile, test-compile or package (in case you depend on the jar). I wonder if we should allow pulling in test-jars from outside the reactor. I know it is possible, but it is a codesmell to me, especially in the JPMS world. (and if overcomplicates the code) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#27?email_source=notifications&email_token=AEKICU3P5UEJOLDA6WDOQWTQ4YPTRA5CNFSM4J33NR7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEINT3II#issuecomment-572210593>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEKICUYAVNE2ZV2MTPIJDRTQ4YPTRANCNFSM4J33NR7A> .

No guessing by artifact name.

floison51 · 2020-01-09T19:40:52Z

Just an idea: To me, problem comes from test artifact which is not modularized. I will experiment auto-modularization of dependent test artifact (use apache-felix maven plugin). If it works, I'll tell you. François Le jeu. 9 janv. 2020 à 19:15, François Loison <francois.loison.51@gmail.com> a écrit :

…

OK, I understand why you were reluctant to adress tests jars from repository. *Back to the root cause of the problem:* The simplest solution would be to setup 2 module-info.java : one for artefact, one for test artefact (with a different module name). But IDEs like Eclipse don't support 2 java files with same name, only the main module-info.java is created. Unfortunately, this solution has side-effects on test artefacts inheritancy. If "double chance" solution (guess test artifact names) is not accepted, I don't see possibility of a fix given the single module-info.java assumption. Moreover, surefire plugin 3.0.0-SNAPSHOT has same problem. So I which modify my code to put test inheritancy in main modules. This is not recommended because it adds test dependencies to main module (I will have to filter them from final package). I will also release the pull request without the "double chance" solution. Best regards, François Le mer. 8 janv. 2020 à 20:04, Robert Scholte ***@***.***> a écrit : > If you only need the reactor, please never use install anymore, but just > verify. And with this plugin you should only use compile, test-compile > or package (in case you depend on the jar). > I wonder if we should allow pulling in test-jars from outside the > reactor. I know it is possible, but it is a codesmell to me, especially in > the JPMS world. (and if overcomplicates the code) > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#27?email_source=notifications&email_token=AEKICU3P5UEJOLDA6WDOQWTQ4YPTRA5CNFSM4J33NR7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEINT3II#issuecomment-572210593>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AEKICUYAVNE2ZV2MTPIJDRTQ4YPTRANCNFSM4J33NR7A> > . >

desruisseaux · 2025-04-21T19:24:28Z

This is fixed, under some conditions, by #320. The condition is to use module source hierarchy as described in this wiki page.

If, nevertheless, there is a need for patching a module with a test-jar outside the compilation unit of the patched module (i.e., the other modules who need that test-jar cannot be in the same multi-module project), then this is doable. But I would like to see if the above paragraph can address most common cases first.

jira-importer · 2025-06-16T05:48:26Z

Resolve #577

github-actions · 2025-12-27T03:39:50Z

This pull request is stale because it has been waiting for feedback for 60 days. Remove the stale label or comment on this PR, or it will be automatically closed in 30 days.

Copilot

Pull request overview

This pull request fixes a test compilation issue (MCOMPILER-372) for modularized multi-module Maven projects where test classes depend on test classes from other modules. When a modularized dependency is added, its test jar classes are ignored if added to the classpath. The fix adds these test jars using --patch-module instead.

Changes:

Enhanced test compilation to detect modularized dependencies and patch their modules with test paths
Added reactor project resolution to map module paths to their corresponding test output directories
Created integration test with 4 projects (prj0-3) demonstrating multi-level modularized test jar dependencies

Reviewed changes

Copilot reviewed 21 out of 21 changed files in this pull request and generated 15 comments.

File	Description
src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java	Refactored preparePaths to use patch modules map; added patchModulesForTestDependencies and helper methods to resolve test paths from reactor projects
src/main/java/org/apache/maven/plugin/compiler/AbstractCompilerMojo.java	Added reactorProjects field and getter method to enable access to reactor project information
src/it/MCOMPILER-372_modularized_testjar/*	Integration test structure with 4 modularized projects testing multi-level test jar dependencies

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-11T21:59:50Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

-
-                compilerArgs.add(patchModuleValue.toString());

+                // Patch module to add 


The comment is incomplete - it ends abruptly with "Patch module to add" without finishing the sentence. This should be completed to clearly describe what is being added to the patch module.

Suggested change

// Patch module to add

// Patch module to add main output directory, source roots, and modularized test dependencies

Copilot · 2026-01-11T21:59:50Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+        } catch (IOException e) {
+            throw new RuntimeException(e);
+        }


IOException is being caught and wrapped in a RuntimeException, which loses the exception type information and converts a checked exception to an unchecked one. This could make it harder for callers to handle specific error scenarios. Consider wrapping it in a more specific exception type or propagating the IOException with better context about what failed.

Copilot · 2026-01-11T21:59:50Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+     * Get module test path element from module path element
+     * @param modulePathElt
+     * @return


The javadoc is missing a description for the @param modulePathElt parameter and the @return value. These should be documented to explain what the parameter represents and what is returned.

Suggested change

* Get module test path element from module path element

* @param modulePathElt

* @return

* Get module test path element from module path element.

*

* @param modulePathElt the module path element, typically the main output directory of a module

* @return the corresponding test output directory for the given module path element,

* or {@code null} if no matching test path can be resolved or it does not exist

Copilot · 2026-01-11T21:59:51Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+     * As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path<br/>
+     * We have to add pjr1-tests.jar as --patch-module<p/>


There's a typo in the javadoc comment: "pjr1-tests.jar" should be "prj1-tests.jar" to match the project naming convention used throughout the codebase and examples.

Suggested change

* As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path 

* We have to add pjr1-tests.jar as --patch-module

* As prj1.jar is added as a module, prj1-tests.jar classes are ignored if we add jar class path 

* We have to add prj1-tests.jar as --patch-module

Copilot · 2026-01-11T21:59:51Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+
+                    for (String path : patchModuleEntry.getValue()) {
+                        patchModuleValue.append(path).append(PS);
+                    }


The patch module value will have a trailing path separator (PS) after the loop completes. For example, if there are two paths, the result would be "moduleName=path1:path2:" with an extra colon at the end. This trailing separator should be removed after the loop to ensure the --patch-module argument is correctly formatted.

Suggested change

}

}

if (!patchModuleEntry.getValue().isEmpty()) {

patchModuleValue.setLength(patchModuleValue.length() - 1);

}

Copilot · 2026-01-11T21:59:52Z

src/it/MCOMPILER-372_modularized_testjar/prj1/pom.xml

+	    <groupId>junit</groupId>
+	    <artifactId>junit</artifactId>
+	    <version>3.8.2</version>
+	    <scope>test</scope>


The indentation uses tabs instead of spaces, which is inconsistent with the XML file's general indentation style. This dependency declaration should use spaces to match the surrounding code.

Suggested change

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>3.8.2</version>

<scope>test</scope>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>3.8.2</version>

<scope>test</scope>

Copilot · 2026-01-11T21:59:53Z

src/it/MCOMPILER-372_modularized_testjar/prj3/pom.xml

+	  <groupId>junit</groupId>
+	  <artifactId>junit</artifactId>
+	  <version>3.8.2</version>
+	  <scope>test</scope>


The indentation uses tabs instead of spaces, which is inconsistent with the XML file's general indentation style. This dependency declaration should use spaces to match the surrounding code.

Suggested change

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>3.8.2</version>

<scope>test</scope>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>3.8.2</version>

<scope>test</scope>

Copilot · 2026-01-11T21:59:53Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+     * As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path<br/>
+     * We have to add pjr1-tests.jar as --patch-module<p/>
+     * @param mainModuleName
+     * param mainModuleTarget


The @param documentation is malformed. The second parameter "mainModuleTarget" is missing the "@" symbol and appears as "param mainModuleTarget" instead of "@param mainModuleTarget". This will cause the javadoc to be incorrectly formatted.

Suggested change

* param mainModuleTarget

* @param mainModuleTarget

Copilot · 2026-01-11T21:59:53Z

src/main/java/org/apache/maven/plugin/compiler/TestCompilerMojo.java

+     * As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path<br/>
+     * We have to add pjr1-tests.jar as --patch-module<p/>


There's a typo in the javadoc comment: "pjr1-tests.jar" should be "prj1-tests.jar" to match the project naming convention.

Suggested change

* As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path 

* We have to add pjr1-tests.jar as --patch-module

* As prj1.jar is added as a module, prj1-tests.jar classes are ignored if we add jar class path 

* We have to add prj1-tests.jar as --patch-module

Copilot · 2026-01-11T21:59:54Z

src/it/MCOMPILER-372_modularized_testjar/prj0/pom.xml

+			     </sources>
+                 <packageName>prj0.conf</packageName> 
+                 <outputDirectory>${project.build.directory}/generated-sources/xjcConf</outputDirectory>
+		      </configuration>


The indentation uses tabs instead of spaces, which is inconsistent with the XML file's general indentation style. This should use spaces to match the surrounding code.

Suggested change

</sources>

<packageName>prj0.conf</packageName>

<outputDirectory>${project.build.directory}/generated-sources/xjcConf</outputDirectory>

</configuration>

</sources>

<packageName>prj0.conf</packageName>

<outputDirectory>${project.build.directory}/generated-sources/xjcConf</outputDirectory>

</configuration>

floison51 added 3 commits December 17, 2019 13:46

[MCOMPILER-372] - integration test

68c84b4

[MCOMPILER-372] - add dependent modules test path as --patchModule

a6379ab

compiler argument

Merge branch 'master' of https://github.com/loizbak/maven-compiler-pl…

20baf7f

…ugin.git

[MCOMPILER-372] added Prj0 to test compilation with JAXB XSD to java

c9bc4df

generation

floison51 closed this Dec 20, 2019

This comment was marked as resolved.

Sign in to view

floison51 reopened this Dec 20, 2019

This comment was marked as outdated.

Sign in to view

floison51 added 5 commits January 3, 2020 17:54

[MCOMPILER-372] added log4j dependency to Prj0 to test test-compile with

3fd2a26

module

[MCOMPILER-372] added log4j dependency to Prj0 to test test-compile with

ac47aa6

module

[MCOMPILER-372] Prj3 to test 2 levels of module usage

ad4bb3c

[MCOMPILER-372] for each module, --patch-module add tests artifacts

b086f21

(when existing) For each module : --add-reads <module name>=ALL-UNNAMED given access to classes from unnamed modules (for example JUnit classes)

Merge branch 'master' of https://github.com/loizbak/maven-compiler-pl…

008cb85

…ugin.git

rfscholte reviewed Jan 3, 2020

View reviewed changes

[MCOMPILER-372] First use reactor projects to get test path element from

5430acf

path element, if it does not succeed, guess test path element from path element

rfscholte reviewed Jan 7, 2020

View reviewed changes

[MCOMPILER-372] - Fixed command lines compilation issues for Prj3

da56e60

Prj2 was not uploading test jar to local repo. Prj2 was not opening prj2 package.

[MCOMPILER-372] Reactor is used to get test artifact

f0dfa60

No guessing by artifact name.

chrisvest mentioned this pull request Mar 19, 2021

Add a ByteBuffer based implementation of Buffer netty/netty-incubator-buffer-api#37

Merged

Merge branch 'master' into master

03b7ddd

gnodet changed the title ~~MCOMPILER-372 - fix test compile issue: added dependency test path for modules~~ [MCOMPILER-372] - fix test compile issue: added dependency test path for modules Feb 13, 2023

desruisseaux mentioned this pull request Apr 21, 2025

Refactoring and support of <release> and <module> elements #320

Merged

slawekjaranowski added the waiting-for-feedback Waiting for 90 days until issues or pull request will be closed label Jun 20, 2025

This comment was marked as resolved.

Sign in to view

github-actions bot added the Stale label Aug 20, 2025

desruisseaux changed the base branch from master to maven-compiler-plugin-3.x September 17, 2025 08:24

desruisseaux removed the Stale label Sep 17, 2025

desruisseaux added the 3.x label Oct 27, 2025

github-actions bot added the Stale label Dec 27, 2025

slachiewicz removed the Stale label Jan 11, 2026

slachiewicz requested a review from Copilot January 11, 2026 21:55

Copilot started reviewing on behalf of slachiewicz January 11, 2026 21:55 View session

Copilot AI reviewed Jan 11, 2026

View reviewed changes


		compilerArgs.add(patchModuleValue.toString());

		// Patch module to add

	// Patch module to add
	// Patch module to add main output directory, source roots, and modularized test dependencies

-     * Get module test path element from module path element
-     * @param modulePathElt
-     * @return
+     * Get module test path element from module path element.
+     *
+     * @param modulePathElt the module path element, typically the main output directory of a module
+     * @return the corresponding test output directory for the given module path element,
+     *         or {@code null} if no matching test path can be resolved or it does not exist

		* As prj1.jar is added as a module, pjr1-tests.jar classes are ignored if we add jar class path<br/>
		* We have to add pjr1-tests.jar as --patch-module<p/>

-                    }
+                    }
+                    if (!patchModuleEntry.getValue().isEmpty()) {
+                        patchModuleValue.setLength(patchModuleValue.length() - 1);
+                    }

[MCOMPILER-372] - fix test compile issue: added dependency test path for modules #27

Are you sure you want to change the base?

[MCOMPILER-372] - fix test compile issue: added dependency test path for modules #27

Uh oh!

Conversation

floison51 commented Dec 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

floison51 commented Dec 17, 2019

Uh oh!

This comment was marked as resolved.

This comment was marked as outdated.

rfscholte Jan 3, 2020

Choose a reason for hiding this comment

Uh oh!

floison51 commented Jan 6, 2020 via email

Uh oh!

floison51 commented Jan 7, 2020 via email

Uh oh!

rfscholte Jan 7, 2020

Choose a reason for hiding this comment

Uh oh!

floison51 commented Jan 8, 2020 via email

Uh oh!

rfscholte commented Jan 8, 2020

Uh oh!

floison51 commented Jan 9, 2020 via email

Uh oh!

floison51 commented Jan 9, 2020 via email

Uh oh!

desruisseaux commented Apr 21, 2025

Uh oh!

jira-importer commented Jun 16, 2025

Uh oh!

This comment was marked as resolved.

github-actions bot commented Dec 27, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 11, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

floison51 commented Dec 17, 2019 •

edited

Loading