[prev in list] [next in list] [prev in thread] [next in thread] 

List:       maven-dev
Subject:    Re: Extending reporting management
From:       "Hilco Wijbenga" <hilco.wijbenga () gmail ! com>
Date:       2006-08-16 16:15:49
Message-ID: e95b15950608160915j3a1edd12yb264dd16e94cc88f () mail ! gmail ! com
[Download RAW message or body]

Hi all,

I'm nowhere near being a veteran Maven user let alone competent at
making changes to Maven but a common API for reporting seems like an
important and extremely useful addition to Maven and I'd like to help
out.

On 8/16/06, Arnaud Bailly <abailly@oqube.com> wrote:
:
<snip/>
:
> 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.

Sounds like a good idea.

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

I've been looking for something that would allow me to generate a
single quality number. E.g. a weighted sum of successful unit tests,
code coverage, checkstyle violations, PMD violations.

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

One look and feel for all reports would definitely be a good thing.
Especially, if the look-and-feel is easily changed to reflect the
"company look-and-feel".

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

Nothing beats graphs when trying to impress management. :-) I'd love
to be able to show progress in quality by means of the weighted sum I
mentioned above on a timeline.

> Comments are of course welcomed and sought after.

Well, here you go. I hope you're not too disappointed it's a
not-even-a-contributor replying. :-)

As I mentioned at the top, I'd like to help out with this. I'll start
by getting a Xen box ready for some serious Maven development. ;-)
We'll see what happens.

Cheers,
Hilco

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]