"John Allen" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
