On 20/09/2021 23:15, Rob Bygrave wrote:
/:/
In case it's interesting, one thing that I hit when migrating to
module-info was that a number of the modules are only used in maven
test scope - as such they don't get a /requires/ clause in
src/main/java/module-info. Currently when running tests v
*> is that you expect code outside of your module to locate these resources*
That's right, the external module reading the resources is not application
specific but a library (its job is to "run database migrations" - open
source, published to maven central etc).
The background is that I have an
On 20/09/2021 11:13, Rob Bygrave wrote:
Well ok, silly me really because I think it is now clear that the
"proper answer" is that the module really needs to open the
subdirectories.
opens dbmigration.postgres; opens dbmigration.mysql;
So thanks and apologies Alan. It's all making sense to me n
Well ok, silly me really because I think it is now clear that the "proper
answer" is that the module really needs to open the subdirectories.
opens dbmigration.postgres;
opens dbmigration.mysql;
So thanks and apologies Alan. It's all making sense to me now,
unfortunately I got muddled by that er
*> "dbmigration" resources have not been copied into target/classes?*
target/classes/dbmigration exists *BUT* ... now I noticed that dbmigration
only contained other sub-directories (which then contain the resources). So
putting an empty junk.txt file into dbmigration fixes the problem.
So if the
On 20/09/2021 09:55, Rob Bygrave wrote:
Hi,
I have a case where I believe I have a module where I would like to use:
opens {package};
... *where {package} only contains resources*, there are no .class files in
{package}. Currently when {package} only contains resources, we get an
InvalidModuleD
Hi,
I have a case where I believe I have a module where I would like to use:
opens {package};
... *where {package} only contains resources*, there are no .class files in
{package}. Currently when {package} only contains resources, we get an
InvalidModuleDescriptorException error:
Error occurred
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 appli
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
Hi,
While working on modularization of my application I've noticed
encapsulation rules for non-class-file resources are different depending on
the resource directory names.
It was not quite obvious for me and my colleagues even though it is a part
of the spec. I wonder if this can be possibly cla
10 matches
Mail list logo
