maven-m2-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maczka Michal <>
Subject RE: [jira] Work Started: (MNG-51) Flesh out the report API
Date Thu, 17 Feb 2005 12:27:39 GMT

> -----Original Message-----
> From: Brett Porter []
> Sent: Thursday, February 17, 2005 12:36 PM
> To: Maven 2 Developers List
> Subject: Re: [jira] Work Started: (MNG-51) Flesh out the report API
> Maczka Michal wrote:
> >imo reports should be free to create: 
> >
> >a) multiple files (like javadoc). This is not supported by doxia.
> >b) use random rendering technology (e.g. javadoc or 
> hammurapi use directly
> >html)   
> >  
> >
> random? so you get something different everytime you run it? :)

> >c) reports be binary files e.g. PDFs
> >   (this is not supported by doxia either as doxia is based 
> on Reader/Writer
> >API, while binary files need streams)
> >  
> >
> sure, we can create one that doesn't take a sink and just 
> renders direct
> to the whatever files it wants, which covers all 3.
> >Also what's matter for reporting api is how reports will push the
> >information into web site navigation etc. 
> >  
> >
> I don't think the reports do this - its the responsibility of the site
> plugin, based on its knowledge of the reports in the site. The reports
> are independant.

I mean that reports either can be described using some metadata or have an
API to retrieve such information (e.g. methods like getTititle()).
That's more or less how it works in m1. Report can handle such information
to the place where navigation will be generated and 
there intelligent aggregation may happen.

> >The way in which report will be generated is not that 
> important IMHO. 
> >Surly we can have a group of reports implementing common 
> API, but I think
> >that report generator should do more or less what they do in 
> m1 - create
> >files in well known location which are later processes (or 
> not) by tools
> >like xdoc/doxia/whatever. So the content generation is a 
> separate concern 
> >from the content presentation. 
> >  
> >
> They can create those files if they are to be used for anything else,
> but at the moment streaming it straight to the final HTML is fast and
> easy. 

I have no doubt that nothing can beat it when it comes to speed.

>It's going to be the same level of work wither way - you need to
> write something to process the events to XML, then transform 
> the XML to
> HTML. Here, we handle the events in two different outputs.

My main concern here is that assumption that a report creates only a single
file or even the assumption that this must be something "visual"
is very limited.

One of the requirement which we may take into account is that reports can
create something, which can be used to push that information in the format
which is parsable by computers (e.g. xml/properties file) to other places
(e.g. mutiproject dashboard, database of the historical reports, continuum).

So for example clover report can deliver which can


In continuum such information can be used for example to display history of
code cov. metrics. and show how it is changing from build to build.
You can even imagine that sucess of the build will depend on some metrics
(e.g if they are passing certain treshold).


View raw message