Accessing a main resource while testing in a modular environment.

[TomerFi]

Hey there @sormuras

I'm trying to figure out how to read resources in a modular environment.
As you are the modules master and this is my favorite maven plugin,
I thought I'll run this by you.
😁

I created a testing project:

• A ReadResourceFiles class for reading the content of a resource file and returning it as a String.
• A TextFile txt, the requested resource file.
• A ReadResourceFilesTest class for testing the application.

I have two active branches:

• The master branch with no module descriptors, as seen in this workflow run, works as expected.
• The added-module-descriptor branch, as the name suggests, with module descriptors, as seen in this workflow run, returns null when trying to pick up the file.

Any thoughts about how might I go at it?

[sormuras]

In-module testing is always ... fun.

Your setup reminds me of https://github.com/sormuras/junit-platform-maven-plugin/tree/master/src/it/modular-world-3-main-foo-test-foo -- which doesn't read a resource, yet. I'll give it a shot.

[TomerFi]

👏👏👏👏
This is good stuff, thank you very much!

I was hoping for a solution involving jpms and not maven, the patch-module solution is sweet!

I'm away from my station, I'll try work-around-3 first thing tomorrow morning!
😀

[TomerFi]

@sormuras

None of the workarounds worked for me out-of-the-box,
And I think I have a lead on the source for the issue.

I've tested my theory with a new testing project copied from your modular-world-3-main-foo-test-foo it project.

First of all, replacing the original module-info.java in the test folder:

open module foo {
  requires org.junit.jupiter.api;
}

With a module-info.test will result in:

--add-modules
  foo

--add-opens
  foo/foo=org.junit.platform.commons

--add-reads
  foo=org.junit.jupiter.api

The first thing that happens is an ExceptionInInitializerError is thrown with the following cause:

RuntimeException: foo specified more than once to --patch-module

This makes sense, I think I've noticed while debugging that using module-info.test is doing some patching of its own.

But... that's ok!
Now, the patching is not actually needed anymore,
both main and test resources are accessible for testing.

This is where it gets weirder, you cannot access subfolders.
If you leave your code as-is, it will still fail since it tries to access the file foo/x.txt.

If you move the file outside of the foo sub folder and place it directly in the resources folder.
You can easily access it after modifying the test cases accordingly of course.

Any thoughts?

[sormuras]

Pointers:

• https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String)
• https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/Module.html#getResourceAsStream(java.lang.String)

The latter explains the subfolder access issues: you need to open each of them.

--add-opens
  foo/foo.sub=<module that needs to reflect into package foo.sub>

I guess, the root package is considered to be an illegal package name, therefore a resource placed directly in resources is not encapsulated.

[TomerFi]

You're right, the getResourceAsStream javadoc does explain the root resources not being encapsulated.

I've tried treating the subfolders as a package name and open it for reflection, but to no avail.

I think there may be something more that needs to be done,
Maybe something in the syntax of the file path...
I've tried a couple of variations, can't seem to get this to work.

I've shared the project to github.

[TomerFi]

So... I've made progress.
Opening foo.sub package for reflection in the source module-info.class works well:

module foo {
  opens foo.sub;
}

But when opening foo.sub package within module-info.test,
the resource files are still not accessible:

--add-opens
  foo/foo.sub=org.junit.jupiter.api

I guess I've got the wrong reflecting module.
It's now clear to me how was it working when using module-info.java with an open module statement.

I'll keep investigating...
I just need to locate the module accessing the resources files.