Thanks for your help.
It was failing because I had the "--module" parameter specified before
the "--module-path" parameter:
img/bin/java --module a/a.A --module-path modules
This results in "FindException: Module a not found". It works if I
specify the "--module-path" option first:
img/bin/java --module-path modules --module a/a.A
Similarly for "--upgrade-module-path", it's ignored when specified
after "--module".
I wasn't expecting that options must be given in a specific order; is
this intentional?
Thanks,
--Gunnar
2017-03-13 1:07 GMT+01:00 Mandy Chung <mandy.ch...@oracle.com>:
>
>> On Mar 12, 2017, at 2:52 PM, Alan Bateman <alan.bate...@oracle.com> wrote:
>>
>> On 12/03/2017 21:20, Gunnar Morling wrote:
>>
>>> Hi,
>>>
>>> I've created a custom runtime image using jlink and would like to add
>>> an additional module at execution time which should be the module with
>>> the main class.
>>>
>>> But that additional module is not found when running
>>>
>>> <IMAGE>/bin/java
>>> --module-path path/to/additional-module
>>> --module com.example.additionalmodule
>>>
>
> Is the module name “additional-module” missing in -—module option? I expect
> it be:
> --module additional-module/com.example.additionalmodule
>
> It works for me:
>
> $ image/bin/java --list-modules
> WARNING: Module name "m2" may soon be illegal
> java.base@9-ea
> m2
>
> $ image/bin/java --module-path modules/mods -m m1/p.Hi
>
>>> Then I stumbled upon the --upgrade-module-path option. So I thought I
>>> could add my module to the image at link time and then override it
>>> with a newer version at runtime. But it keeps using the original one.
>> I'm surprised by that because the search order is:
>>
>> [--upgrade-module-path] <system> [--module-path]
>>
>> which <system> is the run-time image. So while --upgrade-module-path is
>> intended for deploying new versions of "upgradeable modules" then I would
>> expect that it would work here.
>
> This should work too.
>
> Mandy
