for reporting, we will need some common grounds in the model classes.
We already had the @Label annotation, but that was removed.
Here's my suggestion:

The report should contain boxes with the reporting commons (see WINDUP-120) for each item.
Each box may either render automatically or using ruleset's template.

The {{Model}}s will contain annotations from Reporting API, denoting certain basic reporting data, presumably to be present for every reportable item:

• @Title String - Title of the reported item. Not Name, that is overused (e.g. all the EE resources will have names).
• @Description String / class - longer description.
• @Icon("resource/path.png") class - Graphical symbol to make the reports more appealing.
• @FoundBy List<Rule> - rules which found the item.
• @Solutions List<Solution> - links to a solutions for given problem - knowledge base?
• @References List<Reference> - links to references for given problem. URLs to docs.

• @Properties Properties / Map<String, String>:
  Many resources will have lists of information, e.g. generic properties, like datasources.
  These properties are not known in advance - they are DB specific, JDBC driver specific, AS specific.
  So instead of having a java property for each, it's way better to have Properties or Map.

Properties won't be present in all models, but will be quite common, so it should have support in core.

This would be backed by an util class which would extract these info from a Class<?>.
This is usable in both XSLT and FreeMarker reporting, since it's at the lowest level - at model classes.

Now to the implementation.

Many models, basically all root models, will have (should have)

• visuals - @Title @Description @Icon
• references - @FoundBy @Solutions @References

@Title, @Decription, and @Icon can be derived from the data contained + annotations data (E.g. EL + values). I have some coding in progress for this.

@FoundBy, @Solutions, and @References will need some identical code in each model. Using inheritance is nonsense in this case.

So instead of adding all that boilerplate code to every model where it's needed (even worse, formatted by the current terrible formatting rules),
I'd create a class containing all these, add it as a member to the model. And instead of @Adjacency, I'd use @ReportItemInfo and a MethodHandler to store it directly to the given vertex, as if the adjacencies where right in there. Or not? Do we want additional intermediate vertex as a wrapper?