DepAn now imports GraphML files
DepAn now imports GraphML files
DepAn Support For GraphML files
Recent git pushes add a new GraphML (DepanGraphML) plugin to the base DepAn product. The new plugin adds the ability to import GraphML content into DepAn. Interested users should be able to access these capabilities in any recent build of DepAn.
This simple GraphML support only handles GraphML files generated by the Maven dependency:tree mojo. This simple support is readily extended to other GraphML content with different data types, graph elements, and relations.
Analyzing GraphML Files
The GraphML plugin add a New Wizard that handles importing a GraphML file. From New Wizard dialog, select the “New GraphML Analysis” wizard. On the New GraphML Analysis page, enter the name of the GraphML file to process. Although there is a option for Processing, the only valid selection here is “Maven”.
Through the use of the Maven Processing option, the selected GraphML file is converted into a DepAn Graph Information file (*.dgi). The graph uses the same elements and relations provided by the Maven (DepanMaven) plugin.
Gathering Maven Dependencies
The Maven mojo dependency:tree outputs a GraphML representation of Maven’s internal dependency model. Normal use for DepAn importing is:
mvn dependency:tree -DoutputType=graphml -DoutputFile=tree.graphml
If you don’t specify the outputFile (e.g. tree.graphml), the GraphML output is written to the Maven console output. The dependency data is not accessible in that format.
Assuming you use an aggregate master project, an outputFile is created in every project directory. In order to get a complete mapping, you will need to import each outputFile and merge the dependency graphs into a composite.
The dependency data collected from the GraphML output is surprisingly different from the dependency analysis from the Maven plugin. For Tycho projects, many of the target platform dependencies are resolved as system-scope dependencies. The Maven plugin captures property dependencies, and this information is not available in the GraphML output. Resolution of these inconsistencies remains an open problem.
Potential Improvements
Today’s implementation is just the basics. A rich GraphML importer would allow other plugins to contribute processing choices. Many GraphML inputs could be handled by user defined tables. As the capabilities get richer, the underlying XML API should be namespace aware.