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 2006/02/20 02:03:54 UTC
Re: [M2] Dashboard Plugin Plans
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 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