Or in the Maven sandbox, that'd be a more appropriate place :-) (I'm only talking about the "standardized report" framework that Joakim introduced, of course)
On 1/31/07, Garvin LeClaire <[EMAIL PROTECTED]> wrote:
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] > > > > > >
