On Thu, 2004-05-06 at 00:48, Vincent Massol wrote: > Hi Jerome, > > I'm also working on this subject so that's great someone else is also > interested!
Vincent, Thanks for the answer > The goal is to be able to gather data from all existing "quality" > plugins like junit, jdepend, checkstyle, PMD, etc into one single report > and to perform analysis of data over time, trends, etc. > > I've been thinking about 2 ways to achieve this: > > Solution1: > > This is what I have started with the dashboard plugin. As you've > probably seen it provides an aggregated static view of these quality > data. It doesn't support history for a very simple reason: I wanted to > separate the 2 features. Thus, I've started a history plugin which goal > is to save data over time. Then, my idea was to provide other plugins > that will do the analysis of data, correlate them, draw graphs, etc. > > Thus to summarize my strategy was to do it with 3 steps: > - step1: create aggregated data report plugin (this is the dashboard > plugin) > - step2: create a history plugin which allows to save the history of any > report (including the dashboard report, but also any other report like > the checkstyle report, etc) > - step3: create analysis plugins that show trends, with color > highlighting when thresholds are crossed, etc > > For the history plugin, here's how I imagine implementing it: > - history data is saved in the Maven repository under a "report" type, > i.e. under groupId/reports/artifactId-<report date>.<report type, say > xml> > - there is a goal to install/deploy reports to the repository > - there are goals to download reports matching some criteria (groupId, > artifactId, range of date, etc). > - there is also a need for a special file in groupId/reports/ that > provides information on what reports exist in the repository. Let's call > this file reportlist.xml. This file is automatically modified by the > history plugin when a report is uploaded/installed in the repository. > This is required because there's no way to query the repository for the > list of files available. > > Solution 2: > > I've posted an entry about this one in my blog (I'm offline and I don't > remember the entry title but it's something like "wanted: a common API > for storing parsing data"). The idea is to do what CAST Software is > doing with their product: they have parsers that parse source code > (java, c#, SQL, etc) and that store this raw data (with dates) in a > database. Then they have analyzers that query the database and generate > reports. > > The problem in open source is that each tool has its own format and we > don't have a common storage area and common API to store parsing data > in, say, a database. What we could do would be to create a project that > takes different input files (checkstyle report file, PMD report file, > Simian report file, Clover report files, etc) and save them under a > common format in a database. Then we could wrap this project with a > Maven plugin so that it is integrated with Maven and knows the location > of the different plugin reports. > > Then the second step would be to develop analyzer plugins that query > this database to generate reports. > > This strategy is a bit similar with solution 1 but is better structured > in the sense that there is a common pivot format and it goes through a > database which makes it scalable in term of queries. > > I would prefer this solution. me too. > Now that we have good pure java databases, like Hypersonic SQL, I think > it would be easy to have a "database" artifact type, so that we can save > the database content in binary format in the repository (in order to > share it with other users of course). That would be instead of saving > the raw data as in solution 1. What would be save are the data in the > pivot format and in queryable format. Hmm I wonder how would interact with my idea to create the data retroactively. > Of course all this means there is "someone" (a single person) who is in > charge of generating these reports and saving them in the repository. It > makes sense that this "someone" is the continuous build process or the > nightly build process. agree. > Would you be interested in working on this? yes. Now just have to find the time to do it... I've got already 2-3 other projects I've promised to commit some time on, so I won't be able to put real engineering time until let's say early June (hope so). But if we can keep the discussion going, maybe I can start putting some effort then. If by the end of June we see that the idea has grown sufficiently, we may even be able to meet for real to discuss it further as I should be in Paris for a week. > Thanks > -Vincent > > PS: I'm currently offline traveling to TSSS2004. I hope I can find some > internet connection to post this... It'll probably be at least 1 or 2 > days old when you receive it... :-) no problem: I am currently offline most of the time, travelling to PTTSA2004 (*). I manage to connect usually once a day. So it'll probably be at least 1 or 2 days old when you receive it PTTSA2004: Personal Trip to South America 2004 ;) Have fun there. J --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
