Review request for JDK-8156575: Add jdeps -addmods, -system, -inverse options
Mandy Chung
mandy.chung at oracle.com
Thu May 19 17:47:37 UTC 2016
> On May 19, 2016, at 8:20 AM, Daniel Fuchs <daniel.fuchs at oracle.com> 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
More information about the core-libs-dev
mailing list