All, Re dashboards: the reporting aspect of this space is TBH the most trivial aspect of a much wider problem domain, namely that of metrics management and processing, think datum acquisition, storage, manipulation and obviously reporting/access - think OLAP; think CMMI; think corporate governance regimes, gets hairy pretty quick. I have spent the last 12 months reviewing various solutions for an enterprise scale solution for this space and unfortunately there is nothing truly attractive out there so we're going our own way and employing some of Pentaho's open source OLAP framework to provide a basis for our future extendibility and functional needs. The generation of the metrics is trivial however we have still had to re-write all of the main Maven 'code checker' plugins (PMD, FindBugs, Checkstyle, Clover, Cobertura, JIRA (for bug metrics), JDepend, etc) [summary: separate checking from reporting, enable module aggregation, enforce limits/checking, upload to repository, develop static 'dashboard' report plugin, develop J2EE 'slice and dice' system for interactive reporting and analysis]. The trick with this like any information processing problem is the information model you employ. If I was doing this for the maven community I would insist upon integrating the solution with Maven's dependency management system and not just rely on some n-tier data source (JDBC, whatever) to stuff the metrics into. A much cleverer scheme could be based around a federated distributed database accessible via Wagon. Someone mentioned something about using RDP about 6 months ago...
The reason this has been talked about by many but progressed by few is that it seems simple on the surface but in fact, to be worthy of the Maven/Apache name (i.e. done right, based on excellent analysis) it is in fact a hardcore problem. Good luck though, if I was looking to form a new IT company this would the area I would do it in, we are all investing very heavily in governance, not just within the ALM but across broader process spaces and to do so one needs this kind of system. John -----Original Message----- From: Fabrice Bellingard [mailto:[EMAIL PROTECTED] Sent: 31 January 2007 17:06 To: Maven Developers List Subject: Re: [PROPOSAL] Standard Reporting Joakim is definitely right: the dashboard plugin would only be one consumer. What's more, Maven can generate only static pages while the application I'm talking about is a dynamical web application, with far more possibilities than just generated web pages. As for creating a new maven top level projet for the reporting framework that would be embeded in Maven, let's see what the PMCs think about all this! :-) On 1/31/07, Joakim Erdfelt <[EMAIL PROTECTED]> wrote: > > The dashboard plugin is definitely within the scope of this proposal, > but is still just 1 consumer of the datapoint data. The dashboard > plugin would be definitely be affected dramatically by this concept, it > would no longer need to know what the other reports are, how they are > formatted, etc. > > Should we create a new maven top level project for this? Ala WAGON / > SCM / ARCHIVA / CONTINUUM ? > > - Joakim Erdfelt > > dvicente wrote: > > why don't you join the common effort with dashboard project? > > > > see : http://jira.codehaus.org/browse/MSITE-189 (Coordinate the efforts > of > > several users to write a Dashboard Plugin for Maven 2) > > > > or http://docs.codehaus.org/display/MAVEN/Maven+Dashboard > > > > I think that the same idea ? > > > > David > > > > > > bellingard wrote: > >> 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] > >>>> > >>>> > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
