> On May 19, 2016, at 8:20 AM, Daniel Fuchs <[email protected]> wrote:
>
> Hi Mandy,
>
> I played with that a bit (-I/-addmods) and it looks good.
>
> 92 main.opt.I=\
> 93 \ -I -inverse Analyzes the dependences per other
> given options\n\
> 94 \ and then find all artifacts that
> directly\n\
> 95 \ and indirectly depend on the
> matching nodes.\n\
> 96 \ This is equivalent to the inverse
> of\n\
> 97 \ compile-time view analysis and
> print\n\
> 98 \ dependency summary. This option
> must use\n\
> 99 \ with -requires, -package or -regex
> option.
>
> Maybe it would be useful to clarify that the 'artifacts'
> found by the -I option are jars and modules (not classes and packages).
> That was not clear for me when I started playing with it, until
> you explained it.
>
-ct -compile-time Compile-time view of transitive dependencies
i.e. compile-time view of -R option.
Analyzes the dependences per other given
options
If a dependence is found from a directory,
a JAR file or a module, all classes in that
containing archive are analyzed.
This defines what compile-time view analysis means.
> Also it's not clear if there's any difference between
> -m <module> and
> -addmods <module>
> (if you give a single module to addmods).
> Maybe there isn't and maybe it's fine.
>
-m specifies the root module to be analyzed.
In some cases, you will need to specify -addmods to include more modules in the
graph for analysis or needed for the resolution (e.g. java.se.ee is not in the
default policy as specified in JEP 261).
> No need for a new webrev - I'll let you decide whether you want
> to bring in the above clarifications...
Thanks. I’ll push as is and we could tweak the help message as a follow-up
issue.
Mandy
