You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Mauro Botelho <ma...@gmail.com> on 2005/11/29 20:49:38 UTC
Re: [M2] Dashboard Plugin Plans
Did anybody put any more work on this?
I started to look at Brett's suggestions, but could not link the names
to the classes.
Looking at some of the plugins (Surefire, checkstyle and pmd) I think
that when Brett mentions that we have the parsers, I think he's talking
about the PmdReportListener, CheckstyleReportListener and an instance of
org.codehaus.surefire.report.Reporter for example. Is that correct?
Currently most of the plugins hardcode their "parsers" based on specific
rules. To force the plugins to create and maintain the parsers might
be too intrusive.
Is there a lower level that we could use for this integration? Was it
the intention to use a different SiteRenderer for this?
Mauro
Brett Porter wrote:
> (comments also added to the wiki).
>
> I think we should layer this. We already have the parsers for the
> reports, and could attach listeners that generate/update the metric data.
>
> From there, we need an aggregation step (Which the reports need to do
> also), and then the dashboard is a summary of those aggregations, but
> could also be a summary on a per-project level.
>
> I'd like to see this work without a database to get to this stage, and
> then add historical ability as a "bonus".
>
> How does this sound? Can we contact xradar and see if they are
> interested along with David?
>
> - Brett
>
> David Le Strat wrote:
>
>
>>Vincent,
>>
>>Thanks for the diagram. I started experimenting a
>>little bit. I need some time to come up with a solid
>>approach so far though. I am looking forward to your
>>input and comments. I am making the assumption that
>>there will be a dashboard project with the following
>>subsystems (similar to your diagram):
>>
>>- Parser, data collectors: API will have to be
>>specified. Some plugins such as the PMD work in
>>memory, this may require to incorporate a listening
>>mechanism for data collection in such plugins.
>>- Data repository: How should the collected data be
>>organized.
>>- Data aggregation and Dashboard generation: I have
>>been exploring the possibility of embedding BIRT from
>>the eclipse project. Any strong opinion on the list
>>on doing so? I believe that this would allow the
>>dashboard to easily be customizable for different cuts
>>of data aggregation using BIRT's design capabilities.
>>The key here is to define the type of data that should
>>be collected.
>>
>>I am currently further exploring the BIRT embedding.
>>How do you want to pursue on this? Should I submit
>>patches as I move along?
>>
>>Regards,
>>
>>David Le Strat.
>>
>>--- Vincent Massol <vm...@pivolis.com> wrote:
>>
>>
>>
>>
>>>Hi David,
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: David Le Strat [mailto:dlestrat@yahoo.com]
>>>>Sent: lundi 26 septembre 2005 04:27
>>>>To: Maven Developers List
>>>>Subject: Re: [M2] Dashboard Plugin Plans
>>>>
>>>>Thanks for the response I will enter my requests
>>>>
>>>>
>>>
>>>for
>>>
>>>
>>>
>>>>features in Jira. If nobody has started working
>>>>
>>>>
>>>
>>>on
>>>
>>>
>>>
>>>>such plugin, I may go ahead. I just wanted to
>>>>
>>>>
>>>
>>>make
>>>
>>>
>>>
>>>>sure I was not duplicating any work.
>>>>
>>>>Does anyone have any strong opinion on how
>>>>
>>>>
>>>
>>>different
>>>
>>>
>>>
>>>>they want the design for the new plugin to be from
>>>>
>>>>
>>>
>>>the
>>>
>>>
>>>
>>>>M1 one?
>>>>
>>>>
>>>
>>>Yes, I've been thinking about this one for a very
>>>long time... It's a
>>>complex project and it requires a separate project
>>>to be set (same as Maven
>>>SCM, Maven Wagon, etc). It could be called "Maven
>>>Dashboard", "Maven
>>>Quality", "Maven Metrics", etc.
>>>
>>>The main architectural decision is that it requires
>>>a Database to store all
>>>parsed results and analysis.
>>>
>>>Here's the architecture I would use:
>>>http://people.apache.org/~vmassol/dashboardv2.jpg
>>>
>>>Then, after this "Maven Dashboard" project is
>>>created we could have a
>>>Dashboard plugin in Maven proper that would use it
>>>and integrate it with
>>>Maven.
>>>
>>>I also know that Jason and Brett have some ideas on
>>>this topic.
>>>
>>>Thanks
>>>-Vincent
>>>
>>>
>>>
>>>
>>>>Regards,
>>>>
>>>>David Le Strat.
>>>>
>>>>--- Edwin Punzalan <ep...@exist.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>>Hi, David.
>>>>>
>>>>>I doubt if anyone is working on the Dashboard
>>>>>plugin... right now, we
>>>>>are focusing on higher priority plugins towards
>>>>>
>>>>>
>>>
>>>the
>>>
>>>
>>>
>>>>>lesser ones. We'll
>>>>>soon get there ^_^
>>>>>
>>>>>But still, anyone can contribute and start on
>>>>>
>>>>>
>>>
>>>the
>>>
>>>
>>>
>>>>>Dashboard plugin, it
>>>>>they want. We do appreciate volunteers. :D
>>>>>
>>>>>I suggest you also send your feature/mojo
>>>>>
>>>>>
>>>
>>>requests
>>>
>>>
>>>
>>>>>as jira improvement
>>>>>requests here:
>>>>>
>>>>>
>>>
>>>http://jira.codehaus.org/browse/MOJO.
>>>
>>>
>>>
>>>>>That way, you can
>>>>>monitor its progress and probably the plugin
>>>>>
>>>>>
>>>
>>>author
>>>
>>>
>>>
>>>>>could comment/ask
>>>>>more information about it.
>>>>>
>>>>>Thanks
>>>>>
>>>>>
>>>>>David Le Strat wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>All,
>>>>>>
>>>>>>I am not sure what the plans are for the
>>>>>>
>>>>>>
>>>
>>>dashboard
>>>
>>>
>>>
>>>>>>plugin for M2. According to the WIKI, it may
>>>>>>
>>>>>>
>>>
>>>need
>>>
>>>
>>>
>>>>>to
>>>>>
>>>>>
>>>>>
>>>>>>be significantly rewritten. Is anyone
>>>>>>
>>>>>>
>>>
>>>currently
>>>
>>>
>>>
>>>>>>working on the plugin for M2?
>>>>>>
>>>>>>What are the requirements for the M2 dashboard
>>>>>>
>>>>>>
>>>>>
>>>>>plugin?
>>>>>
>>>>>
>>>>>
>>>>>>In addition to the what the M1 plugin
>>>>>>
>>>>>>
>>>
>>>provides:
>>>
>>>
>>>
>>>>>>- Aggregation of information for all
>>>>>>
>>>>>>
>>>
>>>subprojects
>>>
>>>
>>>
>>>>>>presenting them in a single tabular format for
>>>>>>
>>>>>>
>>>
>>>a
>>>
>>>
>>>
>>>>>given
>>>>>
>>>>>
>>>>>
>>>>>>point in time.
>>>>>>
>>>>>>I can think of additional useful requirements
>>>>>>
>>>>>>
>>>
>>>such
>>>
>>>
>>>
>>>>>as:
>>>>>
>>>>>
>>>>>
>>>>>>- Changes over time of the aggregated data for
>>>>>>
>>>>>>
>>>
>>>all
>>>
>>>
>>>
>>>>>>subprojects.
>>>>>>- Developer view of the dashboard where the
>>>>>>
>>>>>>
>>>>>
>>>>>aggregated
>>>>>
>>>>>
>>>>>
>>>>>>data relates to the developer rather than the
>>>>>>subproject for a point in time as well as
>>>>>>historically.
>>>>>>
>>>>>>I guess if historical is supported, point in
>>>>>>
>>>>>>
>>>
>>>time
>>>
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>
>>>>>>also included in this view.
>>>>>>
>>>>>>I would be interested in understanding who is
>>>>>>
>>>>>>
>>>>>
>>>>>involved
>>>>>
>>>>>
>>>>>
>>>>>>in the current plugin. I am willing to help
>>>>>>
>>>>>>
>>>
>>>with
>>>
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>implementation. Has anyone started to think
>>>>>>
>>>>>>
>>>
>>>about
>>>
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>
>>>>>>implementation for M2, has any work already
>>>>>>
>>>>>>
>>>>>
>>>>>started?
>>>>>
>>>>>
>>>>>
>>>>>>How is it being distributed?
>>>>>>
>>>>>>I looking for to your response.
>>>>>>
>>>>>>Regards,
>>>>>>
>>>>>>David Le Strat.
>>>>>>
>>>>>>________________________
>>>>>>David Le Strat
>>>>>>Blogging @ http://dlsthoughts.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>__________________________________________________
>>>>
>>>>
>>>>
>>>>>>Do You Yahoo!?
>>>>>>Tired of spam? Yahoo! Mail has the best spam
>>>>>>
>>>>>>
>>>>>
>>>>>protection around
>>>>>
>>>>>
>>>>>
>>>>>>http://mail.yahoo.com
>>>>>>
>>>>>>
>>>>>>
>>>
>>>---------------------------------------------------------------------
>>>
>>>
>>>
>>>>>>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>________________________
>>>>David Le Strat
>>>>Blogging @ http://dlsthoughts.blogspot.com
>>>>
>>>>__________________________________________________
>>>>Do You Yahoo!?
>>>>Tired of spam? Yahoo! Mail has the best spam
>>>>
>>>>
>>>
>>>protection around
>>>
>>>
>>>
>>>>http://mail.yahoo.com
>>>>
>>>>
>>>>
>>>>
>>
>>---------------------------------------------------------------------
>>
>>
>>
>>>>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
>>>
>>>
>>>
>>
>>=== message truncated ===
>>
>>
>>________________________
>>David Le Strat
>>Blogging @ http://dlsthoughts.blogspot.com
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Tired of spam? Yahoo! Mail has the best spam protection around
>>http://mail.yahoo.com
>>
>>---------------------------------------------------------------------
>>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: [M2] Dashboard Plugin Plans
Posted by dvicente <dv...@gmail.com>.
Hi,
i have developed the Maven Dashboard plugin ( hosted by Codehaus).
And i have many discussions with Garvin LeClaire about the Dashboard Quality
application
as http://jira.codehaus.org/browse/MOJO-732
http://jira.codehaus.org/browse/MOJO-732 and here
http://docs.codehaus.org/display/MAVEN/Maven+Dashboard Maven Dashboard .
where are we be able to find this new API ?
thanks for all.
brettporter wrote:
>
> Sorry for the late reply.
>
> The default is to be a singleton, but I think it only lives as long as
> it's ref count is > 0. So you probably want to set it to the true
> singleton. I remember seeing someone note this recently for something
> else, but I don't know if it exists in the current version of Maven.
>
> In the interim, create a static field that is initialised to the
> component on first use. That's obviously a bit gross but it will keep
> the ref count up until we can determine if the proper way is available.
>
> - Brett
>
> Mauro Botelho wrote:
>> I created a new library like you suggested, and modified both the
>> checkstyle
>> an pmd plugins to use it by adding the new library as a dependency. When
>> I
>> run them individually everything works fine and I see their metrics being
>> reported, but when I try to run both in the same build, I only see the
>> metrics of the last plugin run (in my case checkstyle).
>>
>> I think this has to do with classloading and the way plexus loads its
>> components. The metrics library has a components.xml file in its jar, so
>> I
>> think that the registry singleton is being created by the plugin
>> classloader.
>>
>> What would be the best way to ensure that the registry is a singleton for
>> the build?
>>
>> Here's my components.xml:
>>
>> <component-set>
>> <components>
>> <component>
>> <role>org.apache.maven.metrics.MetricRegistry</role>
>> <implementation>org.apache.maven.metrics.DefaultMetricRegistry
>> </implementation>
>> </component>
>> </components>
>> </component-set>
>>
>>
>> Mauro
>>
>> On 2/19/06, Brett Porter <br...@apache.org> wrote:
>>> It would just need to be a common dependency. reporting-api definitely
>>> is, but you could easily create a new library for it (and that probably
>>> makes more sense).
>>>
>>> The component definition goes in the same JAR as the class.
>>>
>>> - Brett
>>>
>>> Mauro Botelho wrote:
>>>> Brett, in order for any plug-in to use the MetricRegistry, would it
>>>> have
>>> to
>>>> be declared in the reporting-api? Where would I add the component
>>> definition
>>>> for it?
>>>>
>>>> Mauro
>>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
--
View this message in context: http://www.nabble.com/-M2--Dashboard-Plugin-Plans-tf343999s177.html#a10619992
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: [M2] Dashboard Plugin Plans
Posted by Brett Porter <br...@apache.org>.
Sorry for the late reply.
The default is to be a singleton, but I think it only lives as long as
it's ref count is > 0. So you probably want to set it to the true
singleton. I remember seeing someone note this recently for something
else, but I don't know if it exists in the current version of Maven.
In the interim, create a static field that is initialised to the
component on first use. That's obviously a bit gross but it will keep
the ref count up until we can determine if the proper way is available.
- Brett
Mauro Botelho wrote:
> I created a new library like you suggested, and modified both the checkstyle
> an pmd plugins to use it by adding the new library as a dependency. When I
> run them individually everything works fine and I see their metrics being
> reported, but when I try to run both in the same build, I only see the
> metrics of the last plugin run (in my case checkstyle).
>
> I think this has to do with classloading and the way plexus loads its
> components. The metrics library has a components.xml file in its jar, so I
> think that the registry singleton is being created by the plugin
> classloader.
>
> What would be the best way to ensure that the registry is a singleton for
> the build?
>
> Here's my components.xml:
>
> <component-set>
> <components>
> <component>
> <role>org.apache.maven.metrics.MetricRegistry</role>
> <implementation>org.apache.maven.metrics.DefaultMetricRegistry
> </implementation>
> </component>
> </components>
> </component-set>
>
>
> Mauro
>
> On 2/19/06, Brett Porter <br...@apache.org> wrote:
>> It would just need to be a common dependency. reporting-api definitely
>> is, but you could easily create a new library for it (and that probably
>> makes more sense).
>>
>> The component definition goes in the same JAR as the class.
>>
>> - Brett
>>
>> Mauro Botelho wrote:
>>> Brett, in order for any plug-in to use the MetricRegistry, would it have
>> to
>>> be declared in the reporting-api? Where would I add the component
>> definition
>>> for it?
>>>
>>> Mauro
>>>
>> ---------------------------------------------------------------------
>> 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: [M2] Dashboard Plugin Plans
Posted by Mauro Botelho <ma...@gmail.com>.
I created a new library like you suggested, and modified both the checkstyle
an pmd plugins to use it by adding the new library as a dependency. When I
run them individually everything works fine and I see their metrics being
reported, but when I try to run both in the same build, I only see the
metrics of the last plugin run (in my case checkstyle).
I think this has to do with classloading and the way plexus loads its
components. The metrics library has a components.xml file in its jar, so I
think that the registry singleton is being created by the plugin
classloader.
What would be the best way to ensure that the registry is a singleton for
the build?
Here's my components.xml:
<component-set>
<components>
<component>
<role>org.apache.maven.metrics.MetricRegistry</role>
<implementation>org.apache.maven.metrics.DefaultMetricRegistry
</implementation>
</component>
</components>
</component-set>
Mauro
On 2/19/06, Brett Porter <br...@apache.org> wrote:
>
> It would just need to be a common dependency. reporting-api definitely
> is, but you could easily create a new library for it (and that probably
> makes more sense).
>
> The component definition goes in the same JAR as the class.
>
> - Brett
>
> Mauro Botelho wrote:
> > Brett, in order for any plug-in to use the MetricRegistry, would it have
> to
> > be declared in the reporting-api? Where would I add the component
> definition
> > for it?
> >
> > Mauro
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: [M2] Dashboard Plugin Plans
Posted by Brett Porter <br...@apache.org>.
It would just need to be a common dependency. reporting-api definitely
is, but you could easily create a new library for it (and that probably
makes more sense).
The component definition goes in the same JAR as the class.
- Brett
Mauro Botelho wrote:
> Brett, in order for any plug-in to use the MetricRegistry, would it have to
> be declared in the reporting-api? Where would I add the component definition
> for it?
>
> Mauro
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [M2] Dashboard Plugin Plans
Posted by Mauro Botelho <ma...@gmail.com>.
Brett, in order for any plug-in to use the MetricRegistry, would it have to
be declared in the reporting-api? Where would I add the component definition
for it?
Mauro
On 1/24/06, Brett Porter <br...@apache.org> wrote:
>
> This looks good to me at first blush. Please make sure this gets
> captured in the wiki.
>
> As far as the matric registry goes, if you use a singleton component
> then you will guarantee each gets the same. Is that what you needed?
>
> /** @component */
> private MetricRegistry registry;
>
> This is going to need to be in a common dependency of all the plugins
> using this.
>
> - Brett
>
>
>
> Mauro Botelho wrote:
> > I'd like to propose a solution for this. Here's an attempt to describe
> > what I was able to put together, but I'd like the opinion of the
> > community before I get too deep :)
> >
> > First of all, I'm following the approach that has been documented in the
> > wiki so far. The main difference is that instead of persisting to a
> > database right away, I decided to create a MetricRegistry interface.
> > Implementer would then be free to decide what kind of persistence they'd
> > like.
> >
> > This MetricRegistry interface has only 2 method so far:
> >
> > void reportMetric(Object location, String reportName, String metric,
> > Number value);
> >
> > Number getMetric(Object location, String reportName, String metric)
> > throws MetricNotFoundException;
> >
> > Location is an object that would reflect an "abstract project tree". In
> > other words, for Java for example we can come up with a tree of:
> >
> > project -> package -> file -> class -> line -> column
> > -> line -> column
> >
> > where plug ins would report metrics for.
> >
> > ReportName/metric is the metric itself, for example the checkstyle plug
> > in reports counts per severity, so we would have the metrics:
> >
> > checkstyle:errors
> > checkstyle:warnings
> > checkstyle:info
> >
> > and for PMD we could have
> >
> > pmd:violation
> > pmd:files
> >
> > Value is the actual value of the metric. The reason why it is an Number
> > right now is that it would allow a null value representing a not
> > applicable kind of use case.
> >
> > As for the parsers, the plug-ins themselves would either provide the
> > parser as is the case right now with the checkstyle plug-in. They would
> > be responsible for reporting the metrics to the registry. When/if a
> > abstract project tree is created, plug-ins could be expected to report
> > their metrics using locations determined by this APT. This would allow
> > us to eventually create merged reports for statistics. Think of a report
> > crossing checkstyle violations, coverage and volatility for each file in
> > a project.
> >
> > One could ask why not let plug-ins report their analysis against the APT
> > and then have something come and traverse the tree to generate the
> > report, separating the analysis from the report itself. That is a
> > possibility, the problem is that we couple all the plug-ins against an
> > implementation of a unified APT that doesn't exist today.
> >
> > This solution would not address the Admin and Analyzer boxes in
> > Vincent's diagram. Those could be fulfilled by other tools like
> > suggested in the wiki. The registry persister could then save the
> > information in a way that tools would be able to report on it.
> >
> > Here are a few implementation questions I have.
> >
> > I'd prefer that this metric registry be populated by the plug ins as
> > they are run for the site plug-in report. The dashboard would then be a
> > report that would run last and just be a HTML, DB, XML rendition of the
> > metric registry. I'm not sure how this would work in a multi module
> build.
> >
> > I think that a sensible approach would be to allow plug-ins to define a
> > MetricRegistry property that would be configured in the pom and set by
> > the maven engine. Would that break the reporting API contract for
> > example? What is the best way to make sure that there's only one
> > instance of the metric registry per "build".
> >
> > Could we reuse the site plug-in to populate/report the metric registry,
> > or would it be better to be a separate plug-in? I really would like to
> > avoid running the same reports multiple times in the same build. The
> > main reason for that is that we have a dysfunctional project which takes
> > 15 mins to run its unit tests (more of an integration test really),
> > today it takes 1h to run a site: 15 mins for the coverage report, 15
> > mins for the test report for both the site and the dashboard-single
> > reports.
> >
> >
> > Mauro
> >
> >
> > ---------------------------------------------------------------------
> > 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: [M2] Dashboard Plugin Plans
Posted by Brett Porter <br...@apache.org>.
This looks good to me at first blush. Please make sure this gets
captured in the wiki.
As far as the matric registry goes, if you use a singleton component
then you will guarantee each gets the same. Is that what you needed?
/** @component */
private MetricRegistry registry;
This is going to need to be in a common dependency of all the plugins
using this.
- Brett
Mauro Botelho wrote:
> I'd like to propose a solution for this. Here's an attempt to describe
> what I was able to put together, but I'd like the opinion of the
> community before I get too deep :)
>
> First of all, I'm following the approach that has been documented in the
> wiki so far. The main difference is that instead of persisting to a
> database right away, I decided to create a MetricRegistry interface.
> Implementer would then be free to decide what kind of persistence they'd
> like.
>
> This MetricRegistry interface has only 2 method so far:
>
> void reportMetric(Object location, String reportName, String metric,
> Number value);
>
> Number getMetric(Object location, String reportName, String metric)
> throws MetricNotFoundException;
>
> Location is an object that would reflect an "abstract project tree". In
> other words, for Java for example we can come up with a tree of:
>
> project -> package -> file -> class -> line -> column
> -> line -> column
>
> where plug ins would report metrics for.
>
> ReportName/metric is the metric itself, for example the checkstyle plug
> in reports counts per severity, so we would have the metrics:
>
> checkstyle:errors
> checkstyle:warnings
> checkstyle:info
>
> and for PMD we could have
>
> pmd:violation
> pmd:files
>
> Value is the actual value of the metric. The reason why it is an Number
> right now is that it would allow a null value representing a not
> applicable kind of use case.
>
> As for the parsers, the plug-ins themselves would either provide the
> parser as is the case right now with the checkstyle plug-in. They would
> be responsible for reporting the metrics to the registry. When/if a
> abstract project tree is created, plug-ins could be expected to report
> their metrics using locations determined by this APT. This would allow
> us to eventually create merged reports for statistics. Think of a report
> crossing checkstyle violations, coverage and volatility for each file in
> a project.
>
> One could ask why not let plug-ins report their analysis against the APT
> and then have something come and traverse the tree to generate the
> report, separating the analysis from the report itself. That is a
> possibility, the problem is that we couple all the plug-ins against an
> implementation of a unified APT that doesn't exist today.
>
> This solution would not address the Admin and Analyzer boxes in
> Vincent's diagram. Those could be fulfilled by other tools like
> suggested in the wiki. The registry persister could then save the
> information in a way that tools would be able to report on it.
>
> Here are a few implementation questions I have.
>
> I'd prefer that this metric registry be populated by the plug ins as
> they are run for the site plug-in report. The dashboard would then be a
> report that would run last and just be a HTML, DB, XML rendition of the
> metric registry. I'm not sure how this would work in a multi module build.
>
> I think that a sensible approach would be to allow plug-ins to define a
> MetricRegistry property that would be configured in the pom and set by
> the maven engine. Would that break the reporting API contract for
> example? What is the best way to make sure that there's only one
> instance of the metric registry per "build".
>
> Could we reuse the site plug-in to populate/report the metric registry,
> or would it be better to be a separate plug-in? I really would like to
> avoid running the same reports multiple times in the same build. The
> main reason for that is that we have a dysfunctional project which takes
> 15 mins to run its unit tests (more of an integration test really),
> today it takes 1h to run a site: 15 mins for the coverage report, 15
> mins for the test report for both the site and the dashboard-single
> reports.
>
>
> Mauro
>
>
> ---------------------------------------------------------------------
> 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: [M2] Dashboard Plugin Plans
Posted by Mauro Botelho <ma...@gmail.com>.
I'd like to propose a solution for this. Here's an attempt to describe
what I was able to put together, but I'd like the opinion of the
community before I get too deep :)
First of all, I'm following the approach that has been documented in the
wiki so far. The main difference is that instead of persisting to a
database right away, I decided to create a MetricRegistry interface.
Implementer would then be free to decide what kind of persistence they'd
like.
This MetricRegistry interface has only 2 method so far:
void reportMetric(Object location, String reportName, String metric,
Number value);
Number getMetric(Object location, String reportName, String metric)
throws MetricNotFoundException;
Location is an object that would reflect an "abstract project tree". In
other words, for Java for example we can come up with a tree of:
project -> package -> file -> class -> line -> column
-> line -> column
where plug ins would report metrics for.
ReportName/metric is the metric itself, for example the checkstyle plug
in reports counts per severity, so we would have the metrics:
checkstyle:errors
checkstyle:warnings
checkstyle:info
and for PMD we could have
pmd:violation
pmd:files
Value is the actual value of the metric. The reason why it is an Number
right now is that it would allow a null value representing a not
applicable kind of use case.
As for the parsers, the plug-ins themselves would either provide the
parser as is the case right now with the checkstyle plug-in. They would
be responsible for reporting the metrics to the registry. When/if a
abstract project tree is created, plug-ins could be expected to report
their metrics using locations determined by this APT. This would allow
us to eventually create merged reports for statistics. Think of a report
crossing checkstyle violations, coverage and volatility for each file in
a project.
One could ask why not let plug-ins report their analysis against the APT
and then have something come and traverse the tree to generate the
report, separating the analysis from the report itself. That is a
possibility, the problem is that we couple all the plug-ins against an
implementation of a unified APT that doesn't exist today.
This solution would not address the Admin and Analyzer boxes in
Vincent's diagram. Those could be fulfilled by other tools like
suggested in the wiki. The registry persister could then save the
information in a way that tools would be able to report on it.
Here are a few implementation questions I have.
I'd prefer that this metric registry be populated by the plug ins as
they are run for the site plug-in report. The dashboard would then be a
report that would run last and just be a HTML, DB, XML rendition of the
metric registry. I'm not sure how this would work in a multi module build.
I think that a sensible approach would be to allow plug-ins to define a
MetricRegistry property that would be configured in the pom and set by
the maven engine. Would that break the reporting API contract for
example? What is the best way to make sure that there's only one
instance of the metric registry per "build".
Could we reuse the site plug-in to populate/report the metric registry,
or would it be better to be a separate plug-in? I really would like to
avoid running the same reports multiple times in the same build. The
main reason for that is that we have a dysfunctional project which takes
15 mins to run its unit tests (more of an integration test really),
today it takes 1h to run a site: 15 mins for the coverage report, 15
mins for the test report for both the site and the dashboard-single reports.
Mauro
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [M2] Dashboard Plugin Plans
Posted by Brett Porter <br...@apache.org>.
Sorry for the delayed response. It's that time of year :)
Mauro Botelho wrote:
> Is the idea to capture detailed information for each plug in or just
> high level statistics like the old dashboard used to do?
I'd like each plugin to be able to have its own stats so they can easily
do some form of aggregation of their own content without having to
rewrite that code in every reporting plugin. However, having standard
elements that can be used to produce the dashboard would be very helpful.
>
> What I have in place today, is a simple class that has the project id
> (from the pom), stat id (defined by the parser), value (I'm using
> Number here to allow for flexibility). The idea of the stat id is
> that a single plug in can generate multiple stats like the checkstyle
> plug in currently generates number of files, errors, warnings, etc.
Sounds like a good start.
>
> One thing that I'd like to avoid is to run the reports more than once.
> In other words, if the surefire report was already ran, just capture
> the stats from it.
That would be up to the plugin by determining the file exists and its
inputs haven't changed. Future versions of Maven will facilitate doing
this in a declarative way.
>
> How would you pass information from one report back to the "dashboard"
> report? I've been trying to figure out this from the documentation but
> has not been able to find it out yet...
The dashboard, as an aggregator, will have ${reactorProjects}. The
dashboard probably needs to know which files to aggregate from. Either
we'd use the plugin context here or have a standard naming scheme. I'm
not sure at this point.
>
> I'm very willing to help, just don't know where to start :)
>
Dig in if you find something that works for you! We can keep discussing
ideas here if it helps.
Thanks,
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [M2] Dashboard Plugin Plans
Posted by Mauro Botelho <ma...@gmail.com>.
Is the idea to capture detailed information for each plug in or just
high level statistics like the old dashboard used to do?
What I have in place today, is a simple class that has the project id
(from the pom), stat id (defined by the parser), value (I'm using Number
here to allow for flexibility). The idea of the stat id is that a
single plug in can generate multiple stats like the checkstyle plug in
currently generates number of files, errors, warnings, etc.
One thing that I'd like to avoid is to run the reports more than once.
In other words, if the surefire report was already ran, just capture the
stats from it.
How would you pass information from one report back to the "dashboard"
report? I've been trying to figure out this from the documentation but
has not been able to find it out yet...
I'm very willing to help, just don't know where to start :)
Mauro
Brett Porter wrote:
> Mauro Botelho wrote:
>
>>Did anybody put any more work on this?
>
>
> No, not yet. I'm thinking of spending some time on it soon.
>
>
>>I started to look at Brett's suggestions, but could not link the names
>>to the classes.
>>
>>Looking at some of the plugins (Surefire, checkstyle and pmd) I think
>>that when Brett mentions that we have the parsers, I think he's talking
>>about the PmdReportListener, CheckstyleReportListener and an instance of
>>org.codehaus.surefire.report.Reporter for example. Is that correct?
>
>
> Basically, yes.
>
>
>>Currently most of the plugins hardcode their "parsers" based on specific
>> rules. To force the plugins to create and maintain the parsers might be
>>too intrusive.
>
>
> These will always be necessary to produce a feature rich report.
> Probably what we need is a common set of aggregation data points that
> the parsers can filter these into.
>
>
>>Is there a lower level that we could use for this integration? Was it
>>the intention to use a different SiteRenderer for this?
>
>
> I dont think it would be a site renderer, but another report.
>
> - Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [M2] Dashboard Plugin Plans
Posted by Brett Porter <br...@apache.org>.
Mauro Botelho wrote:
> Did anybody put any more work on this?
No, not yet. I'm thinking of spending some time on it soon.
>
> I started to look at Brett's suggestions, but could not link the names
> to the classes.
>
> Looking at some of the plugins (Surefire, checkstyle and pmd) I think
> that when Brett mentions that we have the parsers, I think he's talking
> about the PmdReportListener, CheckstyleReportListener and an instance of
> org.codehaus.surefire.report.Reporter for example. Is that correct?
Basically, yes.
>
> Currently most of the plugins hardcode their "parsers" based on specific
> rules. To force the plugins to create and maintain the parsers might be
> too intrusive.
These will always be necessary to produce a feature rich report.
Probably what we need is a common set of aggregation data points that
the parsers can filter these into.
>
> Is there a lower level that we could use for this integration? Was it
> the intention to use a different SiteRenderer for this?
I dont think it would be a site renderer, but another report.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org