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 09:35:18 GMT

> -----Original Message-----
> From: []
> Sent: Thursday, February 17, 2005 4:32 AM
> To:
> Subject: [jira] Work Started: (MNG-51) Flesh out the report API

I just want to share my ideas regarding reporting in m2. 

I think that we should start with the "definition" what's actually report

I am not really agreeing with first approximation of Brett which is:

public interface MavenReport
    String ROLE = MavenReport.class.getName();

    void execute( Sink sink )
        throws MavenReportException;

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
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)

Also what's matter for reporting api is how reports will push the
information into web site navigation etc. 
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. 

Don't get me wrong I am all for using doxia in cases when it makes sense
(e.g. for creating usual set of reports from POM directly to html).
But I don't think that this is really all we can expect from reporting api
and that it is covering all the use cases. 
I propose to start with something simple and concrete: project team report
and javadoc report and see how both of them can be produced by m2 report



View raw message