[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

floison51 · 2019-12-20T19:58:54Z

Discarded, new pull request to follow

floison51 · 2019-12-20T20:04:41Z

Closed by mistake.

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> > . >

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

floison51 reopened this Dec 20, 2019

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

floison51 commented Dec 17, 2019 •

edited

Loading

floison51 commented Dec 17, 2019

floison51 commented Dec 20, 2019

floison51 commented Dec 20, 2019

rfscholte Jan 3, 2020

floison51 commented Jan 6, 2020 via email

floison51 commented Jan 7, 2020 via email

rfscholte Jan 7, 2020

floison51 commented Jan 8, 2020 via email

rfscholte commented Jan 8, 2020

floison51 commented Jan 9, 2020 via email

floison51 commented Jan 9, 2020 via email

[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

Conversation

floison51 commented Dec 17, 2019 • edited Loading

floison51 commented Dec 17, 2019

floison51 commented Dec 20, 2019

floison51 commented Dec 20, 2019

rfscholte Jan 3, 2020

Choose a reason for hiding this comment

floison51 commented Jan 6, 2020 via email

floison51 commented Jan 7, 2020 via email

rfscholte Jan 7, 2020

Choose a reason for hiding this comment

floison51 commented Jan 8, 2020 via email

rfscholte commented Jan 8, 2020

floison51 commented Jan 9, 2020 via email

floison51 commented Jan 9, 2020 via email

floison51 commented Dec 17, 2019 •

edited

Loading