"Graph -> Frames -> JAXB => XML -> XSLT => HTML" based reporting

ReportItem is the top-level "unit" of the reportable info, which would

• create boxes in the report
• be linked to other report items
• would appear in various index pages
• could share templates and styles
• could be filtered by facetes (using JS on a static page)
  etc.

My current effort aims to provide as easy reporting as possible.
In my PoV, one way to do it would be to add few metadata to the *Model classes, as described in that jira.

By reading the metadata, processing the EL expressions with the model instance (frame), it would get a basic info to add to the report.
Currently implemented approach is too template-based, IMO, and templates will get a real mess quite soon.
What I would like is to offload a rational amount of structure, CSS and JS to shared generic templates, which would handle the common cases when you only need to report things whose info struture is just Icon, Title, Description, properties, and perhaps some links. That worked very nicely in WindRide.
Then there would be few predefined templates for tabular data, code snippets, etc. (Imagine putting just an instance of
@Template(CODE_SNIPPET)
class JavaDeprecatedApiUsageModel
with FileLocationModel to the graph, and it would appear in the report, in an index of the report, in a table of all java code problems, etc.

In general, I want to stick to few concepts - graph, Gremlin, BeanValidation, EL, JAXB, XSLT, CSS, JavaScript (jQuery). These combined, and used in a systemic way, can give very powerful, yet maintainable reporting.

For more complex items, e.g. rendering of a picture, the models could still define a custom renderer, anything resulting in HTML.