#CompileTimeDependencies and module resolution

When you have a module A with an optional dependency on B (`requires static B`), module B is not resolved from the module path unless `--add-modules B` is provided at startup (tested with jigsaw-b151). In [1] this is mentioned as a detail, and in fact it is phrased as a question there. Is this

Re: #CompileTimeDependencies and module resolution

Hi Sander, you're right, it's a bug, --add-modules should not be necessary. Rémi - Mail original - > De: "Sander Mak" > À: "jigsaw-dev" > Envoyé: Vendredi 13 Janvier 2017 11:39:10 > Objet: #CompileTimeDependencies and module resolution &

Re: #CompileTimeDependencies and module resolution

On 13/01/2017 11:08, Remi Forax wrote: Hi Sander, you're right, it's a bug, --add-modules should not be necessary. Rémi I don't think there is a bug here. Instead the example that Sander has chosen doesn't resolve a module that `requires B`. The "Notes" section in #CompileTimeDependences prop

Re: #CompileTimeDependencies and module resolution

The standard use case for the feature is for libraries with optional dependencies: module Lib { requires static A; requires B; } module A { ... } module B { ... } Given this setup: module App1 { requires Lib; } the module graph should include App1, Lib and B. Any use of A from Lib must be guarde

Re: #CompileTimeDependencies and module resolution

> The standard use case for the feature is for libraries with optional > dependencies: That is indeed the use case I was thinking of. > The --add-modules flag is only relevant when using the command line to > turn setup #1 into setup #2, something which should be rare. Interesting, so what you'

Re: #CompileTimeDependencies and module resolution

t; , "Sander Mak" > Cc: "jigsaw-dev" > Envoyé: Vendredi 13 Janvier 2017 12:33:53 > Objet: Re: #CompileTimeDependencies and module resolution > On 13/01/2017 11:08, Remi Forax wrote: > >> Hi Sander, >> you're right, it's a bug, --add-modules shou

Re: #CompileTimeDependencies and module resolution

On 13/01/2017 12:48, Sander Mak wrote: : Alternatively, you can view optional dependency usage more like 'if the application already uses A, then Lib should also use A as well' in which case your suggested setup and the current implementation make total sense. This does make the example I des

Re: #CompileTimeDependencies and module resolution

On 13 Jan 2017, at 14:37, fo...@univ-mlv.fr wrote: As i've read the mail of Sander, the module which is required statically is present in the module path but not resolved by default, you have to use --add-modules. But maybe i'm wrong ? You're not wrong, see the email e

Re: #CompileTimeDependencies and module resolution

On 01/13/2017 06:48 AM, Sander Mak wrote: The standard use case for the feature is for libraries with optional dependencies: That is indeed the use case I was thinking of. The --add-modules flag is only relevant when using the command line to turn setup #1 into setup #2, something which sho

Re: #CompileTimeDependencies and module resolution

- Mail original - > De: "David M. Lloyd" > À: "Sander Mak" , "jigsaw-dev" > > Envoyé: Vendredi 13 Janvier 2017 15:23:56 > Objet: Re: #CompileTimeDependencies and module resolution > On 01/13/2017 06:48 AM, Sander Mak wrote: >> >

Re: #CompileTimeDependencies and module resolution

Ok, thanks. Rémi - Mail original - > De: "Sander Mak" > À: "jigsaw-dev" > Envoyé: Vendredi 13 Janvier 2017 14:47:59 > Objet: Re: #CompileTimeDependencies and module resolution > On 13 Jan 2017, at 14:37, fo...@univ-mlv.fr<mailto:fo...@univ-mlv.fr

Re: #CompileTimeDependencies and module resolution

> On 13 Jan 2017, at 14:45, Alan Bateman wrote: > > >> : >> Alternatively, you can view optional dependency usage more like 'if the >> application already uses A, then Lib should also use A as well' in which >> case your suggested setup and the current implementation make total sense. >> Thi