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]
