On 09/04/2020 19:23, Eirik Bjørsnøs wrote:
Alan,
If I read your mail correctly, you are creating "multi-module JAR
files"
where the modules are "exploded" under /META-INF/modules in
${NAME}-${VERSION} directories.
Correct.
Do they need to be "exploded"? If the dependences are
On Thu, Apr 9, 2020 at 7:37 PM Alan Bateman wrote:
The only packaging format for automatic modules that Java SE defines is
> JAR files. The "Multi-release JAR files" feature is also JAR file only.
>
My ModuleFinder for exploded-within-jar automatic modules needed a
ModuleReader implementation.
On Thu, Apr 9, 2020 at 5:42 PM Eirik Bjørsnøs wrote:
Here's a strawman API which I think would support my use case :
>
> ModuleFinder auto = ModuleFinder.automatic(Path location, String
> defaultName, Set packages, Set serviceNames)
>
Another thought...
Since ModuleReader already has the
On 10/04/2020 10:53, Eirik Bjørsnøs wrote:
:
Is it safe to assume that all access to content with a module happens
through the ModuleReader?
Yes, the ModuleReader is the only way to access the contents of a module
so you'll see all class loading, finding resources, etc. all go through
the
>
> Do they need to be "exploded"? If the dependences are automatic modules
> then I assume putting the JAR files (without unpacking) into
> META-INF/modules should just work without needing a new ModuleFinder
> implementation or implementing the exploded equivalent of multi-module JAR
> files (or
On Fri, Apr 10, 2020 at 5:00 PM Alan Bateman
wrote:
>
> This would require the API specify how automatic modules are created
> from the contents of "something" that already have a ModuleReader.
> Specification could be crafted of course but I have concerns that it
> goes beyond the original
On 10/04/2020 11:14, Eirik Bjørsnøs wrote:
:
Since ModuleReader already has the list() method, code in java.lang.module
could use that to scan for packages and service names it needs to derive
automatic ModuleDescriptors.
Clients would now only need to pass the custom module reader and a
