Module resource loading

[Alexey Gavrilov]

Thanks for taking a look.


> Resource encapsulation is complicated.

Yes, that is very true


In our application we use the TypeSafe’s config library [1] which scans the
application classpath for all resources named like `reference.conf` or
`application.conf`. It works just fine in a modular application, the config
files are in the root directory and not encapsulated. No problems.


We also use the Flyway database migration tool [2] which looks for .sql
files located under `db/migration` directories in the classpath. We used to
have those directories in different modules, which is frankly not a good
idea, Flyway was not able to find the migration .sql files because of the
package split.


We also have some migration files under `db/migration-<database-name>`
directories and noticed that it works differently because of a non-valid
Java character in the directory name. Hence Flyway is able to load the
files located in different modules. And finally our JUnit tests for the
.sql migrations are running in the classpath mode, making it hard to debug.


Based on this experience I’ve created a Flyway feature request [3] for Java
Modules support.


[1] https://github.com/lightbend/config

[2] https://flywaydb.org

[3] https://github.com/flyway/flyway/issues/3196


Best regards,

-Alexey

On Wed, Jun 9, 2021 at 5:08 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 08/06/2021 20:20, Alexey Gavrilov wrote:
> > Note that *Module 2* cannot contain its own resources under `dir1` and
> > `dir2` directories because they are already encapsulated in *Module 1*.
> If
> > you try adding `dir1` you will get the following error:
> >
> >      Error occurred during initialization of boot layer
> >      java.lang.LayerInstantiationException: Package dir1 in both module
> > module_one and module module_two
> Resource encapsulation is complicated.
>
> The basic guideline is that code should use Class::getResourceXXX or
> Module::getResourceXXX to locate a resource in its own module.
> ClassLoader::getResourceXXXX is for locating other resources in other
> components on the class path or module path. Services are often a better
> choice for cases where the resource is configuration that names a class.
>
> Two modules with resources in the same "package" is the same as split
> package issue. Are the two modules in question closely related, meaning
> sharing a name space, or they are completely unrelated?
>
> -Alan.
>