It's packages, not modules, so there can be intra-module package cycles. You could do that, though, by simply collapsing packages before building the graph - if com.foo depends on com.bar, consolidate those into a com.foo/com.bar node, since even though their author may have liked to imagine them as two things, if they mutually depend, that's an illusion, and the reality is they are a single component with a quirky namespace - if you have two things, neither of which can exist without the other, then they are actually one thing, just organized in a confusing way.
What I'm actually doing is running javac - using nb-javac-impl - over the source files, with all of the "keep going even if it's broken" switches turned on - through the parse phase, not attributing, and running a visitor over each CompilationUnitTree in two passes, the first to find all the classes, and the second to build a method -> method called graph. Then spit out a graph file for methods, one for classes based on stripping method info out and using the number of calls between two packages to provide a weight value, and then stripping class names out to do the same for packages. For the entire NetBeans codebase, the class and package graphs are way too large to be renderable. When I originally wrote this, it was to generate graph files for PGX, and I did some playing with using PGX to add properties for pagerank and eigenvector centrality (I think I varied node size by those, although in 3D-land you'd probably want to vary the shape or something, since relative size would just appear to be closer to the camera). Eigenvector centrality is a particularly interesting measure, since you basically get a weight that emphasizes "most likely to be connected *through*" - it emphasizes classes that frequently act as a bridge between components, and those are the things that, when you change their code, are most likely to result in surprising bugs. Pagerank, on the other hand, gives you a measure of "most likely to be connected *to*" which gives you a measure of importance, which is interesting for understanding the architecture, as opposed to for understanding what commits might need extra review. -Tim On Mon, May 14, 2018 at 12:55 AM, Ivan Soleimanipour < [email protected]> wrote: > There aren't supposed to be any dependency cycles so I wonder what would > happen if > you rendered it as a DAG? > > > > > On 05/13/18 20:56, Tim Boudreau wrote: > >> If you took out a few apis used by almost everything - filesystems, >> utilities, progress, data systems in particular, it's not actually that >> bad. >> >> -Tim >> >> On Sun, May 13, 2018 at 6:55 PM Dmitry Avtonomov < >> [email protected]> wrote: >> >> And that horrendous glob of interdependencies is supposed to be a "loosely >>> coupled system"? >>> >>> com.oracle.javafx cluster is nicely disconnected though :) >>> >>> On Sun, May 13, 2018 at 12:51 PM, Efrem Mc <[email protected]> wrote: >>> >>> Hi Tim, that is pretty awesome! >>>> >>>> The 3d graph is nicely connected and with all the 3d effects. >>>> You give is a top level input for the master node, and it follows all >>>> the dependencies? >>>> >>>> >>>> >>>> Thanks for sharing. >>>> >>>> Efrem McCrimon >>>> >>>> >>>> >>>> >>>> On Sun, May 13, 2018 at 1:52 PM, Tim Boudreau <[email protected]> >>>> >>> wrote: >>> >>>> I was playing with the code that used to live in contrib/callgraph - >>>>> something I wrote when I was working on graph analytics stuff for >>>>> >>>> Oracle >>> >>>> Labs, and added d3-friendly output to it. Then ran across a library >>>>> >>>> that >>> >>>> does 3d visualization on top of that. >>>>> >>>>> Here is a graph of package dependencies for the NetBeans source tree. >>>>> >>>> I >>> >>>> intentionally excluded a few classes from org.openide.util (Lookup, >>>>> NbBundle, RequestProcessor), since pretty well everything depends on >>>>> >>>> them: >>>> >>>>> https://timboudreau.com/files/nb-packagegraph/ >>>>> >>>>> -Tim >>>>> >>>>> -- >>>>> http://timboudreau.com >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> For further information about the NetBeans mailing lists, visit: >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>>> >>>> >>>> >>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > -- http://timboudreau.com
