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

Gili commented on SUREFIRE-1811:
--------------------------------

[~sor] To be fair, this topic is quite subjective and strong feelings have been 
expressed on both sides. I'm not trying to blame anyone, but to give you a 
concrete example you wrote above:

> It should *(read: must)* never ever contain directives that only exist to 
> satisfy testing needs.

I think we need to agree that this is a subjective desire, not an objective 
need. Some of us believe that the main module must not refer to the test 
module. Others think there is nothing wrong with it.

To recap once more in case Pavel is not aware of the larger context:
 # To my understanding... We are only talking about the case where one JPMS 
module wishes to access the internals of another JPMS module (white-box 
testing). All other cases work just fine.
 # In an ideal world, integration tests should not access implementation 
details. We are only talking about the theoretical case where this isn't the 
case. This is an exceptional case, not the happy path.

Let's review our options:
 # Why does the test code need to run on the modulepath? You could use JPMS for 
"main" and classpath for "test".
 # You could use use qualified exports and SharedSecrets per 
[https://stackoverflow.com/a/46723089/14731|https://stackoverflow.com/a/46723089/14731.]
 (my approach)
 # You could patch the module path using command-line options (Christian's 
approach)
 # You could add another layer of modules. You could have three Maven modules: 
"common", "production" and "test". "common" is your production code minus JPMS. 
"production" depends on "common" and adds module-info.java. "test" depends on 
"common", adds test-specific code including module-info.java. You then have 
"src/test" in the "test" module which runs your actual integration test. You 
get the power of running on the classpath while still running as a module. The 
downside is the extra project complexity.

>From my perspective: you're saying that "it's not ideal to have the main 
>module contain test-specific code" but your use-case is not ideal either. Your 
>integration test should not reference implementation details. If you fix that 
>underlying problem, all the other problems go away.

> Add resources to JPMS test module
> ---------------------------------
>
>                 Key: SUREFIRE-1811
>                 URL: https://issues.apache.org/jira/browse/SUREFIRE-1811
>             Project: Maven Surefire
>          Issue Type: New Feature
>          Components: Maven Failsafe Plugin
>    Affects Versions: 3.0.0-M5
>            Reporter: Pavel_K
>            Priority: Major
>
> I am testing version 3.0.0-M5 with two module-info in one project - one main 
> and one for test. My test project is here 
> https://github.com/PashaTurok/hibernate-h2-test4 . The problem is with 
> resources. For example, I have  src/main/resources/META-INF/persistence.xml 
> file that is not copied to test module. Because of this it is not possible to 
> find resource in test module and it is necessary to use something like this 
> https://github.com/PashaTurok/hibernate-h2-test4/blob/292e2e683ad72487cbf8d2e5a35dde0d9255001a/src/test/java/com/foo/hibernate/h2/test4/TestIT.java#L72
>  . 
> In target/test-classes/META-INF/jpms.args I see:
> {code:java}
> --patch-module
> my.project=/home/..../hibernate-h2-test4/src/main/java, 
> /home/.../hibernate-h2-test4/target/generated-sources/annotations
> {code}
> As I understand test module will NOT contain resources from the module under 
> test? I mean that test module will NOT contain 
> /home/..../hibernate-h2-test4/src/main/resources? 
> That's why I suggest to include src/main/resources in test module.



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

Reply via email to