Let me fix my over zealeous typing ;-o) Why don't we put the code in the Plugin sandbox at Codehaus? This will give us and others time to "test drive" it and move on from there. I think I need to use the dashboard plugin a little more before we do merging. I could get some of my current users to give feedback also.
-- Regards, Garvin LeClaire [EMAIL PROTECTED] On 1/31/07, Garvin LeClaire <[EMAIL PROTECTED]> wrote:
Why don't we put the code in the Plugin sandbox at Codehaus? This will give us and other to "test drive" it and move on from there. I think i need to use the dashboard plugin a little more before we do merging. I could get some of my current users to give feedback. -- Regards, Garvin LeClaire [EMAIL PROTECTED] 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] > >
