You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Joakim Erdfelt <jo...@erdfelt.com> on 2007/01/30 23:54:46 UTC
[PROPOSAL] Standard Reporting
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
Re: [PROPOSAL] Standard Reporting
Posted by Arnaud Bailly <ab...@oqube.com>.
"John Allen" <jo...@hotmail.com> writes:
> database accessible via Wagon. Someone mentioned something about using RDP
> about 6 months ago...
>
Hello,
I was the one who talked about this 6 months ago :-)
I am still interested in it, and willing to share my ideas and part of
my workforce. One reason I did not produced anything interesting was
the lack of answers to some questions I asked about basic maven
architecture and usage of some of its components. I then switched to
other things, and then 6 months were gone.
Just in case, here is my original mail (august the 16th):
Hello,
Following some quick discussion with Vincent MAssol at maven day paris
in july about a generalised QA tool for maven, I would like to share
some thoughts about report management in maven and how it could (maybe) be
improved.
Currently, report generation in maven2 is largely *ad hoc*: each
plugin (reporting or build plugin) has its own private way of
generating data and generating *views* on this data to be integrated
into the project's site. For example, *surefire* plugin generates XML
reports into the =target/surefire-reports/= directory and these reports
are later processed by *surefire-report* reporting plugin to generate
HTML pages into the =target/site/surefire-reports/= directory. These
HTML pages are decorated as other pages in the site thus providing a
consistent look and feel across reports (and by the way allowing easy
customization of this L&F through CSS files and custom templates).
This is the case for most reports I have used like *pmd*, *cobertura* or
*checkstyle*. Other reports like *javadoc* and *xref* reports generates HTML
pages with their own private format.
As it may be apparent from the questions in the maven users' mailing
list, the aggregation of reports for modules of a project is a
recurring issue. This aggregation must currently be implemented by
each plugin in an *ad hoc* way and it seems this is not a trivial
task. Moreover, the aggregation process may not be easily controlled
in a consistent way: excluding certain projects or part thereof from
aggregation is difficult (or impossible ?).
Furthermore, there is a need for a global and synthetic view
of complex multi modules projects' status and QA information. This
information was provided in **maven 1.X** through the *dashboard* plugin
that could aggregate reports' output in one tabular view.
I think that both issues could benefit from changing the current
approach of report and (meta-)information handling in maven from a
plugin dependent view to a project dependent view.
A project's structure has (at least) two dimensions: A *physical structure* that is
made of files, directories, archives, maybe URLs ; and a *logical
structure* made of modules, packages, classes, methods,
instructions. These two dimensions are obviously related: a class is
*defined* in a file, a package is *implemented* by one or several
directories, a method is *defined* in a class, etc.
Each reporting plugin provides some pieces of information about part
of the stuctural elements of a project:
- Surefire reports give sucess rates and failures explanation for
test cases which are themselves testing methods, classes or modules,
- javadoc report document logical structural elements of a project,
- coverage reports give coverage information about instructions or
lines in files, in relation with test cases.
This latter example further illustrates that information can be added
to information.
The basic idea I have in mind is thus to provide as a core maven
service a central information API that would be used by **all** reporting
plugins to attach information to structural elements of the
project. This information could be store as a RDF (see also
http://www.ilrt.bris.ac.uk/discovery/rdf/resources/) graph backed by
a suitable ontology and extensible at will. The RDF structure would
simplify most of the issues raised earlier in this text as it gives
standard tools to query, aggregate and transform informations stored
in the graph.
Aggregating information, for example, is trivial and can
be done generically at *any* suitable level: If I need coverage percent
for each method, I can query nodes relating to methods for a
=test-coverage= predicate attached to this node and use the given
object's value. Or I can use the same information by aggregating
values at, for example, module scope, following links from module
nodes to =test-coverage= predicates they lead to.
Another interesting aspect of this scheme is that RDF, having an
external XML representation, is amenable to XSLT transformation and
thus can be used uniformly to generate human-readable reports without
resorting to specialized handling per plugin.
Furthermore, storing this information in a versionned database would
allow one to retrieve the *evolution* of the information attached to a
project over time and various builds. This functionality is today provided
by qalab plugin, once again in an *ad hoc* way.
I dont know exactly what development effort this would imply:
1. creating the primary structure from the project at startup
2. populating the RDF database from this primary information gathered
along the way
3. giving access to this database through an API to all plugins
4. providing a transformation framework for easy report generation
from the database and rendering
I think that 2 and 3 above are the same thing: the primary and
secondary information could all be created by the various plugins
involved in a build, with some bootstrapping in 1 to create the basic
structure (projects, modules, base directories...).
Comments are of course welcomed and sought after.
As I said, I am still interested.
Regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, PhD
\tel> (33) 3 59 08 61 98
\mob> (33) 6 17 12 19 78
\web> http://www.oqube.com
RCS Lille B 490 219 730
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [PROPOSAL] Standard Reporting
Posted by John Allen <jo...@hotmail.com>.
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:bellingard@gmail.com]
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 <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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Standard Reporting
Posted by Fabrice Bellingard <be...@gmail.com>.
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 <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
>
>
Re: [PROPOSAL] Standard Reporting
Posted by Vincent Siveton <vi...@gmail.com>.
Hi Joakim,
2007/1/31, Joakim Erdfelt <jo...@erdfelt.com>:
> 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.
Agree.
All plugins are sort of analysis engines for code quality or code
quantity. The dashboard is more for governance, ideally with a depth
notion in the analysis.
The data store should be more like a knowledge base. Actually, a lot
of reports plugins are for java but we need also to support .net with
nmaven and probably other languages like sql.
>
> Should we create a new maven top level project for this? Ala WAGON /
> SCM / ARCHIVA / CONTINUUM ?
+1
Vincent
>
> - 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Standard Reporting
Posted by 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
> > >
> > >
> >
> >
>
Re: [PROPOSAL] Standard Reporting
Posted by Garvin LeClaire <ga...@gmail.com>.
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
> >
> >
>
>
Re: [PROPOSAL] Standard Reporting
Posted by Garvin LeClaire <ga...@gmail.com>.
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
>
>
Re: [PROPOSAL] Standard Reporting
Posted by Joakim Erdfelt <jo...@erdfelt.com>.
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
Re: [PROPOSAL] Standard Reporting
Posted by dvicente <dv...@gmail.com>.
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
>> >
>> >
>>
>>
>
>
--
View this message in context: http://www.nabble.com/-PROPOSAL--Standard-Reporting-tf3145514s177.html#a8731845
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [PROPOSAL] Standard Reporting
Posted by Fabrice Bellingard <be...@apache.org>.
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
> >
> >
>
>
Re: [PROPOSAL] Standard Reporting
Posted by Garvin LeClaire <ga...@gmail.com>.
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
>
>