Hi guys, it seems that this proposal arrives right on time! :-) I've just been hired by a company that has developed, for its own needs, an application that can store code metrics, consolidate them and show them in various ways. I haven't had the time to look more into it yet, but it looks very promising though. So I asked the CEO to open-source it, and he seems ready to go for it if I can find a good place for the project to start (I still need to see that point... I was thinking of proposing it to the Apache Incubator, but I need to dig more into this question).
Maven is a build tool that already produces lots of data that is transformed into static reports. As you said Joakim, this would be *very* valuable to push this data into a data store. Maven could then generate more comprehensive reports from it. Good ! Then, let's say that the data store is the database of the application I just talked about: this would be even more powerful as we would benefit from what already exists in this application (dynamic views, consolidation engine, ...). With such a solution, any kind of complex report becomes easier to develop as long as you have the information (I'm referring to your wild dreaming idea ;-) ). So I'm 100% for encouraging to start designing and then implementing the appropriate hooks into maven 2.1! Cheers, Fabrice. On 1/31/07, Garvin LeClaire <[EMAIL PROTECTED]> wrote:
Joakim, I think that is a good idea. I have thought about this also when I was working on the Findbugs plug-in. I think this would faciliate a more effective way to do dashboard type reports. I was thinking about developing a Doxia JDBCWriter for Plugins to use. I would like to have the ability to have more than one writer for a plug-in. This may be possible but I did not see it. I would think we would embed Derby for simplicity from the support standpoint. This would provide a good self contained reference for a user to get started. Do you have a suggested schema for the database yet? -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 1/30/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: > > There are many reports and plugins now that generate reports against the > code. > > I'd like to see an entire framework built around the concept of > Standardized Reporting. > > The components of this framework... > > maven-reporting-datapoint > > This would provide an API that various reporting plugins (checkstyle / > pmd / findbugs / etc...) can utilize to issue a very generic datapoint > DataPoint.report(Project project, File sourceFile, long line, int > severity, String type, String message); > This API in turn logs the information into a data store (derby / > hsqldb / xmlstore) with a timestamp of its occurance. > This library would also provide an abstract standard report generator > to produce a report that is consistent for all plugins. > > maven-datapoint-report-plugin > > This would provide a report similar to JXR and Cobertura that lists > the source files, complete with hits against each file from all reports > that use the datapoint API. Inline messages and highlighting can be > used to show the line and all problems associated with that line from > each datapoint generator. This information should be produced on a > per-module and aggregated perspective. > A historical graph can be shown from this datapoint information for > that module / project / file. (sparkline) > > What needs to be done is identify the reporting types, and attempt to > define as few 'standard reports' views as possible. > The needs of JDepend is different than PMD or even Cobertura. Heck, a > standard report format might just be a pipe dream, but the rest of the > datapoint proposal should still have merit. > > If this is a good idea, I think we should encourage the appropriate > hooks into maven 2.1 for this functionality, and then work on this as a > seperate concept. > > Wild dreaming ideas. Implement a standard Maven SCM Annotate method so > that datapoints in the code can even be associated to the developer that > created that line, producing historical charts for each developer too! > > - Joakim > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
