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?

Hi Ondra, Have you looked at the reporting code in Windup? We are building data models for each report that contain much of this information (eg, title). I am not sure why we would want to use annotations for this instead of a separate report model?

The @Properties thing is not currently supported by the Graph, though it may be possible to build something approximating it with @JavaHandlers. On 07/15/2014 10:47 AM, Ondrej Zizka wrote: > Hi, > > 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: > > @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. > > JIRA: https://issues.jboss.org/browse/WINDUP-120 > > There are few related: > > WINDUP-103 Create report data model > WINDUP-109 Refactor model classes to support an abstract project model > WINDUP-117 Update reporting to use the new project meta-model for > producing reports (including blacklist reports) > WINDUP-114 Replace ArchiveModelPointer with a > @ArchiveType(value=".war") annotation on the model classes themselves > > Ondra > > > > _______________________________________________ > windup-dev mailing list > windup-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/windup-dev _______________________________________________ windup-dev mailing list windup-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/windup-dev