Re: [PROPOSAL] Standard Reporting

[Fabrice Bellingard <be...@apache.org>]

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 <ga...@gmail.com> 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
> garvin.leclaire@gmail.com
>
>
> On 1/31/07, Garvin LeClaire <ga...@gmail.com> 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
> > garvin.leclaire@gmail.com
> >
> >
> >
> >
> > On 1/31/07, Joakim Erdfelt <jo...@erdfelt.com> 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 <ga...@gmail.com> 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
> > > >>> garvin.leclaire@gmail.com
> > > >>>
> > > >>> On 1/30/07, Joakim Erdfelt <jo...@erdfelt.com> 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: dev-unsubscribe@maven.apache.org
> > > >>>> For additional commands, e-mail: dev-help@maven.apache.org
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
>