Hi Alan.
>> java -p mods --lomit-modules foo -m bar
> This limits the set of observable modules to `bar` plus the
> transitive closure of `foo`.
Ah, now I get it.
You originally wrote:
> The set of observable modules is the the transitive closure of the
> modules you specify to --limit-modules plus any modules that you
> specify to --add-modules or -m (for the main/initial module).
Now I see you meant:
obs = closure( { --limit-modules} ) + --add-modules + --module
I understood:
obs = closure( { --limit-modules + --add-modules + --module } )
:)
so long ... Nicolai
On 28.01.2017 20:32, Alan Bateman wrote:
> On 28/01/2017 18:39, Nicolai Parlog wrote:
>
>> Hi Alan,
>>
>> thanks for your reply. Yes testing is a good example, didn't have
>> that idea. So testing and services, then?
> Yes, and for service providers then you might specify one or two
> to --limit-modules when converging on the set of service provide
> modules to explicit link into a run-time image.
>
>
>> : Based on my observations that is not the case. At least the
>> initial module is _not_ used as a root module to determine the
>> universe of observable modules. This only works if bar is in
>> foo's transitive closure:
>>
>> java -p mods --lomit-modules foo -m bar
> This limits the set of observable modules to `bar` plus the
> transitive closure of `foo`. This will fail immediately if `bar`
> transitively depends on a module that it's in the foo++ set. You
> might need to work through a few examples to convince yourself of
> course.
>
> -Alan
>
--
PGP Key:
http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509
Web:
http://codefx.org
a blog about software development
https://www.sitepoint.com/java
high-quality Java/JVM content
http://do-foss.de
Free and Open Source Software for the City of Dortmund
Twitter:
https://twitter.com/nipafx
