[jira] [Comment Edited] (SUREFIRE-1755) Put dependencies from module-info in test sources on module path

["Gili (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SUREFIRE-1755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17094996#comment-17094996 ] 

Gili edited comment on SUREFIRE-1755 at 4/29/20, 3:07 AM:
----------------------------------------------------------

[~tibordigana] [~rfscholte] I would like to get your feedback on a related use-case that concerns this issue.

I've got a server module that provides "src/main/java/module-info.java" that only depends on server-related dependencies.
I've then got "src/test/java" containing unit tests that depend on the same server dependencies as well as an additional HttpClient dependency needed to test the server.

The way I see it, "main" and "test" are two separate Java Modules where "test" depends on "main" plus has its own set of dependencies. This is why "test" could depend on HttpClient dependencies without the "main" codebase doing the same. My question is:

1. Do you agree with this mental model?
2. How would I represent this use-case using the new mechanism you are introducing into Surefire?

Ideally, I would like Surefire to check for "src/test/java/module-info.java" and if present use that for the "test" module. If the file is missing, use the "module-info.java" found in "src/main/java". If you don't see things the same way, how would I solve this situation using your model?

Thank you.


was (Author: cowwoc):
[~tibordigana] I would like to get your feedback on a related use-case that concerns this issue.

I've got a server module that provides "src/main/java/module-info.java" that only depends on server-related dependencies.
I've then got "src/test/java" containing unit tests that depend on the same server dependencies as well as an additional HttpClient dependency needed to test the server.

The way I see it, "main" and "test" are two separate Java Modules where "test" depends on "main" plus has its own set of dependencies. This is why "test" could depend on HttpClient dependencies without the "main" codebase doing the same. My question is:

1. Do you agree with this mental model?
2. How would I represent this use-case using the new mechanism you are introducing into Surefire?

Ideally, I would like Surefire to check for "src/test/java/module-info.java" and if present use that for the "test" module. If the file is missing, use the "module-info.java" found in "src/main/java". If you don't see things the same way, how would I solve this situation using your model?

Thank you.

> Put dependencies from module-info in test sources on module path
> ----------------------------------------------------------------
>
>                 Key: SUREFIRE-1755
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1755
>             Project: Maven Surefire
>          Issue Type: Wish
>          Components: Maven Surefire Plugin
>    Affects Versions: 3.0.0-M4
>            Reporter: Stephan van Hulst
>            Priority: Minor
>
> When testing a Maven project that contains a {{module-info.java}} in both the main source folder and the test source folder, modules that are required for testing only (such as {{org.junit.jupiter.api}}) are not put on the module path, causing the tests to fail with an exception similar to:
> {code:none}
> java.lang.module.FindException: Module org.junit.jupiter.api not found, required by com.example.module{code}
>  It would be nice if Surefire patched the module-info in the main source folder with extra dependencies from the module-info in the test source folder.
> Example of main {{module-info.java}}:
> {code:java}
> module com.example.module {
>   exports com.example.module;
>   requires com.example.another.module;
> }{code}
> Example of test {{module-info.java}}:
> {code:java}
> open module com.example.module {
>   exports com.example.module;
>   requires com.example.another.module;
>   requires org.junit.jupiter.api;
> }{code}
> This example implies that {{org.junit.jupiter.api}} would be available on the module path during testing, but not during regular compilation and runtime.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)