Good point, John. Hilco, your proposal sounds good in the context of a
single VM invocation when everything is in-memory. How does this extend to
reporting over time? Just as a compiled binary is a "binary snapshot" of
the code at a point in time, we need to take a "report snapshot" with all
this metadata persisted for reporting on a module over time. Perhaps each
report could optionally generate their own OWL metadata which can be
packaged by site into a "reporting archive" JAR and stored in the repo for
each version of a module. We would need a version-based reporting API to
trawl over those versions.
mike
"John Allen" <[EMAIL PROTECTED]> wrote on 08/16/2006 02:19:12 PM:
> Sounds like an excellent proposal. I've been thinking for some time how
we
> might extend maven's reporting fwk to better support metrics management
and
> reporting. Have you considered the means of making this RDF data
> distributable (and re-constitutable) via the maven artifact system?
>
> John
>
> -----Original Message-----
> From: Hilco Wijbenga [mailto:[EMAIL PROTECTED]
> Sent: 16 August 2006 17:16
> To: Maven Developers List
> Subject: Re: Extending reporting management
>
> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
