[
https://issues.apache.org/jira/browse/SUREFIRE-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17147496#comment-17147496
]
Gili edited comment on SUREFIRE-1811 at 6/29/20, 2:09 AM:
----------------------------------------------------------
[~sor]
> Gili - if your main module refers to a test module, you need to publish your
> test module as well. How should a user ever build a working module graph?
Not true. Java ignores unknown qualified exports. I use this design pattern in
my own library
(https://github.com/cowwoc/requirements.java/blob/591e425339d00c03145eca8acadf1f439db6e5eb/java/src/main/java/module-info.java#L24)
and it compiles/loads just fine.
> Ad option 1: Why should test libraries stay on the classpath?
Maybe I missed something, but who says they have to? The user's testcase can
load on the classpath while everything else is on the modulepath. This is
perfectly reasonable to do if you're white-box testing.
> Ad option 3: This is not "Christian's approach" – that's what javac, javadoc,
> java, and friends offer. Patch module was added for testing.
These features allow you to hack the modulepath for exceptional cases. That's
why they're called "patch-module" and are not available from within
module-info.java directly. If JPMS authors would have meant for this to be part
of the happy path they would have let one specify patching directly inside
module-info.java (e.g. in the form of module "inheritance" or "extension"). At
least that's my interpretation. Either way, I agree that this functionality is
available from command-line.
>> [...] Your integration test should not reference implementation details.
>> [...]
> They don't. In-module tests are 90+% pristine unit tests, extra-modular
> tests are my integration tests.
I'm sorry. I still don't understand this part and it's very important to
clarify this. If the integration tests only reference public APIs exported by
main, why do we need to patch the modulepath? What extra stuff are the
integration tests accessing that the production code does not?
was (Author: cowwoc):
[~sor]
> Gili - if your main module refers to a test module, you need to publish your
> test module as well. How should a user ever build a working module graph?
Not true. Java ignores unknown qualified exports. I know because I use
precisely this design pattern in my own library and it compiles/loads just fine.
> Ad option 1: Why should test libraries stay on the classpath?
Maybe I missed something, but who says they have to? The user's testcase can
load on the classpath while everything else is on the modulepath. This is
perfectly reasonable to do if you're white-box testing.
> Ad option 3: This is not "Christian's approach" – that's what javac, javadoc,
> java, and friends offer. Patch module was added for testing.
These features allow you to hack the modulepath for exceptional cases. That's
why they're called "patch-module" and are not available from within
module-info.java directly. If JPMS authors would have meant to be part of the
happy path they would have let one specify patching directly inside
module-info.java. At least that's my interpretation. Either way, I agree that
this functionality is available from command-line.
>> [...] Your integration test should not reference implementation details.
>> [...]
> They don't. In-module tests are 90+% pristine unit tests, extra-modular
> tests are my integration tests.
I'm sorry. I still don't understand this part and it's very important to
clarify this. If the integration tests only reference public APIs exported by
main, why do we need to patch the modulepath? What extra stuff are the
integration tests accessing that the production code does not?
> 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)
