∞ /notes/graphviz-dot-export-for-zest | 2009-06-10 | eclipse graphviz soc zest

Graphviz DOT export for Zest

Cross-posted to: https://fsteeg.wordpress.com/2009/06/10/graphviz-dot-export-for-zest/

I've completed the second milestone of Graphviz DOT as a DSL for Zest, my Google Summer of Code project at Eclipse. Milestone 2 adds basic Graphviz export for Zest by generating DOT files or strings from Zest graph instances. Details can be found on the project's Eclipse wiki page.

Milestone 2 also adds integrated DOT export support to the Zest graphs generated by the Graphviz import for Zest (milestone 1), through a toDot method. I was considering overriding toString in these classes, but while the DOT representation is human-readable, it is not always concise.

I had some doubts using the original JET instead of the new JET2 for generating the DOT representations, but it seems that with JET2 I have to introduce a runtime dependency on the M2T bundles. With the original JET,  a plain Java class is generated at development time that has no additional bundle dependencies at all. This seems very useful in this case, as it would not burden Zest with additional dependencies for the export functionality. So I sticked with that for now. If I'm missing something here I'd be happy about any pointers on how this could be done with JET2.

Implementing the basic export functionality was less work than I had anticipated. I guess one reason for this is the combination of the general simplicity of graphs - just nodes and edges - with the fact that the DOT output is very short and easy to write, even in a template. Also, I did not have to worry about any Zest layout algorithms like for the import, as DOT does not support them in the language itself. This could be tackled in the future by using other Graphviz commands than dot (like circo, neato etc.) once the executable is called as an optional part of the export (planned for milestone 8).

When I look at the code I have written myself to implement the actual functionality (i.e. not generated or testing code), I find it almost scary to see how little that is: about 60 lines for the export (~15 for the JET template and ~45 for the DotExport wrapper class) and about 170 lines for the import (~95 for the Xpand template, ~15 for the generator workflow and ~60 for the DotImport wrapper class).

Thanks to the Ohloh analysis though, I can comfort myself, as it says overall it's at about 1000 lines, so I can see I did write some code. Actually, all I wanted was a timeline or changelog for the complete repository, for me to check up on what I have been doing lately from time to time. Unfortunately this is currently not available for Berlios CVS repositories.

So I looked around for some alternatives, and simply setting up the repository location on Ohloh seemed to be the easiest way. This gets me that complete timeline and more. It's not perfect, though. For instance, it takes 2-4 days to catch up. Also, it feels a bit weird having these contributions to Zest in a project of its own on Ohloh. But Ohloh projects can be closed anytime and in the meantime it's useful to get an overview of the existing code and changes.