[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154191#comment-17154191
]
Pavel_K commented on SUREFIRE-1811:
-----------------------------------
[~cowwoc]
> Okay, so if I understand you correctly nothing is blocking you from running
> white-box unit tests on the classpath.
Here is the question what I can do and what I will do.
# I can use OSGI with JPMS that is suggested now by OSGi alliance (and they
are serious). Can I? Yes, I can. Will I? No, I won't.
# I can within one project use different approaches - main code in JPMS
modules, IT tests in JPMS modules, unit tests on class path. Can I? Yes, I can.
Will I? No, I won't. Here the keyword is "standardization" + JPMS advantages.
For example, to provide services I always use only module-info but not
{{/META-INF/services}}. Another example - I always control modules that are
used during program running via module-info - the keyword is "reliable
configuration".
# I can forget JPMS and use only class path. Guess the answer.
It seems to me, that you miss some important things. You consider using jpms
for running unit modules only for relation between your tests and classes under
test. I agree that it is difficult to see jpms advantage here. However, I
suggest you to look at the whole "application" that is running when your tests
are executed. For example, you have some testing library that you use in your
tests. How will your organize your library? I think you will have some API and
some impl. And I think you would like to hide your impl and open your API
before using this library in 1000 tests. So, the keyword here is
"encapsulation". If you are on class-path forget about some auto control. If
you run your tests in jpms env, jpms will provide you a mechanism to control
access to your impl code. So, here we see a jpms advantage. I think you can
find other advantages by yourself if you look at the problem from this point of
view.
> 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)
