Skip to end of metadata
Go to start of metadata

This page is meant to gather all discussions about the Maven 2 Dashboard. This is about taking the idea of the Maven 1 Dashboard plugin and bringing it to M2 with a cleaner and more scalable design.

Introduction

Some ideas about what the M2 Dasboard is:

  • It is a project separate from m2 core (same as with Maven SCM, Maven Wagon, etc).
  • It could named "Maven Dashboard" for example
  • It is meant to be able to parse any kind of generated data and produce analysis, correlation and display of consolidated data
  • It should support both realtime and history charts over time with trends

[Add more use cases here]

Architecture

Here's a possible architecture:

Implementation ideas

  • It should use a database to allow for powerful querying
  • No labels

16 Comments

  1. I agree we should layer this. We already have the parsers for the reports, and could attach listeners that generate/update the metric data.

    From there, we need an aggregation step (Which the reports need to do also), and then the dashboard is a summary of those aggregations, but could also be a summary on a per-project level.

    I'd like to see this work without a database to get to this stage, and then add historical ability as a "bonus".

    How does this sound? Can we contact xradar and see if they are interested along with David that has expressed interest?

  2. Also agreed, layering is a good idea. I believe that aggregation of data in a database is required for historical. For point in time, Brett has a good point.

    I also think that we should make it easy to create new reports. I have been exploring using BIRT (Eclipse BIRT project). Using BIRT embedded in a plugin would allow us to provide a flexible front end layer to generate reports with a robust set of tools to support it. This would make the dashboard quite flexible for users with custom requirements and to adapt to needs for more sophisticated data aggregation.

    Note: How can we add info to the page rather than a comment? I signed up but still can only submit comments.

  3. Did somebody start working on this yet? In order for me to completely move to m2 I need this report.

  4. Here's what I think we could do:

    Create a "data structure" where we would describe the different levels in Java: Project, package, file, class, method, variable, line, etc.

    And an interface with a getter for a collection of key-value pairs where the key is the above mentioned "data structure" and the value is a java.lang.Number.

    During the report execution, the parser would accumulate the metrics. The site mojo or some other object would then after the execution collect these metrics and persist them.

  5. Hi All,

    Can someone please tell me how to set up Maven on a machine which has no internet access?Like what are various jars to be downloaded so that the basic java:compile goal of maven can be executed. Any information on these would be greatly appreciated. Thanks

  6. Hi,

    I am very interested by this feature, xradar only provide a maven 1 plugin.

    Any plans to implement it ?  

  7. Hi,

    If it is not too much of work, is it possible to provide a basic functionality -- aggregation only (same as maven 1) while maven 2 Dashboard is redesigned and redeveloped ?

     Thanks

  8. Hi, 

    It seems there is no dashboard plugin I will try to develop one. I already made a histoy plugin for maven 1 that picks up all aggregator items and creates historic data.

    I hope to encorporate the next features

     - multiproject aggregation

     - history ( at least xml, preferrably database )

     - project healt indicator based on preconfigured weight distribution over aggregator items

     - support for multiple "standard plugins" 

    I am not promising this will succeed, but when I have a result as with the history plugin for maven 1.0 I will share it.

    Greetz,

    Alex Brussee

  9. Hi,

    Dashboard plugin is a great idea. I'm not sure that having historic and dasboard in the same plugin will be very flexible.

    As I see it, we may have a dashboard-api plugin and a dashboard-report plugin.

    *Dashobard-api may contain interfaces. Implementation have to provides 3 information to the dashobard-report. We may have for exmaple a DashboardInfo interface with

      • Name of the info (for example for surefire number of tests passed)
      • A formatted info (for example an html). dashboard-api has no idea about what is in this field. For example to have a cobertura like state.
        <td>60% </td><td><table class="percentGraph" cellpadding="0" cellspacing="0" width="100"><tr><td class="covered" width="60"></td><td class="uncovered" width="40"></td>
      • A boolean to say if the info reach acceptance criteria.

    A "Dashboardable" plugin should implement dashboard-api. A plugin such as JDepend may return several DashboardInfo.

    *Dashboard report will be in charge of providing a page for the site. It will collect DashboardInfos provided by all the dashboardable plugin (surefire, cobertura, jdepend, pmd, ... for example) (Dashboardable plugin may be listed in the configuration of the plugin). Dashboard info may be display in a table as for maven 1 dashboard plugin. If the acceptance criteria of the DashboardInfo is false it may for example add a failure icon.
    If one Dashboardnfo is in failure we should see a conclusion after the table to say that there is some issues.
    Plugin should be able to write a dashboard for java projects. For aggregation projects (projects with sub modules), it may display the same table with several line, one for each module.

    • For each plugin to include in the dashboard we have to write a plugin that implements the dashboard-api.

    For the history, that's also a good idea. It should be possible to have a common api for history and an implementation for "historizal" plugins ...

    What's your opinion about that ?

  10. Is this a Wiki, I do not seem to be able to add a link under "related links":

    http://qalab.sourceforge.net a Maven 2 plugin is coming soon...

  11. I have developped a dashboard plugin.

    It aggregates surefire, cobertura,checkstyle,pmd and cpd results.

    It works for a single project , generating a single report with all results and JFreeChart graphs

    It works also for a multi-project generating  :

    - a single dashboard report with all results and JFreeChart graphs for each project

    - a global dashboard for each project that has modules :

        - first page is the summary which consolidate results of all sub-modules , with also JFreeChart graphs

        - second page is the detailed report which aggegate all results of sub-modules with also JFreeChart graphs.

    I  also generate an xml file for each project.

    I plan to integrate database support to store results from my xml file and generate historical graphs.

    it must be refactoring to fit all ideas which are explained above.

    I don't know where to submit you an example of Dashboard HTML files before delivering a plugin's version.

  12. I have uploaded a zip file with example of my Dashboard report.

     All your comments will be valuable.

     Thanks

  13. Hi David,

    Would it be possible to upload the Dashboard plugin into Sandbox at https://svn.codehaus.org/mojo/trunk/mojo/mojo-sandbox/&nbsp;or is it available somewhere for me to download and try out.

    Thanks

  14. I have submited my dashboard plugin.

     Dashboard plugin

    I hope you enjoy it 

  15. I think the data should be stored in a database and detail is important if we wish to truly understand our code quality history.
    The current way where QALab and the dashboard plugins are required to gather information throughout different disk levels of the project is some what kludged (sp?).  It requires that these plugins know about all the various plugins output formats.
    A more ideal situation would be to have the plugin writers be able to create output to a standard data model.  I think we are trying to accomplish a similar task as outline by the ISO9126 ( http://en.wikipedia.org/wiki/ISO_9126 ) standard attempts to address.
    This allows the history information to be shared with a wider audience since databases are easier to scale than file systems.  This does allow for more flexible and dynamic reporting options.

    Here are a few ideas I have on items to help address these:

    1. Develop a data model for the database.
    2. Create a Doxia sink writer to write to a database
    3. Future "code quality" plugins would need to modify output options to support this infrastructure if they currently do not support multiple sinks.
    4. A scanner plugin could be developed to scan the different text outputs.  This could be used in the interim.  It should have the ability to build file format extensions for the different report layouts.  The maven-enforcer plugin looks like a good example.

    I would be willing to use the Findbugs plugin I work on to implement a plugin update to support this.  I think we could also look at the checkstyle, PMD, and JDepend plugins.

     Garvin

  16. In September 2006, I've discovered this page written by Vincent which has directly inspired the launch of an Open Source project. One year later we are pleased to announce that Sonar 1.0 release is now available. The missions of Sonar are to :

    • Centralize and share quality information for all projects under continuous quality control
    • Show you which ones are in pain
    • Tell you what are the diseases

    To do that, Sonar aggregates metrics from Checkstyle, PMD, Surefire, Cobertura / Clover and JavaNCSS. You can take a look to the screenshots gallery to get a quick insight.

    Have fun.

    Freddy