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