You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Arnaud Bailly <ab...@oqube.com> on 2006/08/31 11:44:07 UTC
Maven central reporting API
Hi,
A couple of weeks ago I posted a proposal about a centralized
reporting feature for maven that would allow easy aggregation of
information at whatever level is needed. This proposal is centered
around the idea of creating and maintaining a RDF database that could
be used by plugins to find information or store information to be
latter processed by other plugins or external tools.
I am trying to implement a small proof of concept without modifying
maven base codebase and using only plugins. I plan to do the
following:
1. a base plugin to create initially the RDF database and populate it
with basic pom's information
2. a modified compiler plugin to store source files structure
information
3. a modified surefire plugin to store test results in the graph
attached to the test source files and projects
4. a modified test report lpugin that would take advantage of the RDF
graph to generate aggregated reports
I have started learning to use Jena's API which is quite simple and
I am currently stuck with the following problem. A basic feature of
this idea is that inheritance be handled correctly, which means that
if the CreateMojo is invoked in a subproject with its 'inherit'
attribute set to true, then it should attach its informations in its
parents RDF database, not in its own. Furthermore, this should be done
recursively until one reach the toplevel project or 'inherit' is set to
false.
Questions (which may be trivial) are:
1. Is there one mojo instance for each project in the hierarchy ? I
think this is the case but I am not sure.
2. How can I retrieve a mojo instance from another mojo in the same
or a sub project ?
Help appreciated of course :-).
BTW, thinking about all this, it occured to me that maven may be
viewed as an interpreter for a DSL dedicated to software artifacts
construction and management. The language is declarative and takes the
(rather verbose and unhandy) form of an XML dialect.
The various POM's ingredients describes either:
1. data *values*, to be later processed by *functions*: File path
settings, configuration options, project's id card all fall into
this case. These values are organized in a tree such that one can
refer to variable's values using dotted notation (eg. =foo.bar.baz=)
2. *functions* that process the project's data, that is essentially
plugins (essentiallye mojos), which may themselves be parameterized by some more
data or values.
The POM (and maven defaults settings ) itself can be viewed as a
function providing *scheduling* or orchestration of the various *phases* of the build process. The
lifecycle feature of maven gives a declarative way to *hook* functions
invocations (ie. plugins and their contained mojos) or in maven
parlance *binding a mojo to a phase of the lifecycle*.
Sub-modules structure is just plain old function recursion.
Dependency management is preparation step to allow proper linking and
may not be considered part of the "language" it self.
Thinking that way, one can imagine doing the following things:
- provide a non-XML language layer tha would allow expressing a build
process in an easier to use form than what is actually available
- compile the build program for:
- optimizing the build time
- eventually detecting concurrency pattern such that distributed
execution (eg. using compile farms) coul be provided
Is this plain scrap or has someone else already thought about doing
that kind of things ?
regards
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Arnaud Bailly <ab...@oqube.com>.
jallen <jo...@hotmail.com> writes:
Hi John,
> I'm afraid I not replying to answer your questions but I am very excited
> that someone is taking this on!
Encouraging posts are always welcomed :-)
>
> What I have found from promoting a low-cost (read open-source or cheap such
> as JIRA/Confluence) ALM environment based upon Maven and Eclipse (as the
> integration backbones) is that it's Mavens ability to construct a complete
> project portal, snapshotted from the current source base, that has senior
> management, CMMi experts and a industry luminaries alike (no names but we're
> talking gang-of-four level) all 'ooh-ing' in their seats.
I had exactly te same experience with maven the first time I (with
other people from my company) produced our first project's sites.
>
> Information sharing, collaboration and, critically, governance reporting and
> enforcement (be it tests reports, quality metrics, heuristics, plan
My first motivation was in assessing reliability and quality metrics.
>
> The development of a proper maven/apache framework to supports
> report/measure execution, storage, aggregation, distribution, querying,
> publication and of course site integration would result in Maven being
> elevated to the place it always set out to be, project comprehension and
> technical management, and really enable IT organisations to bridge the gap
> between the technical disciplines (code, docs, tests) and the
> managerial/governance disciplines (quality, progress, process). As someone
> who spends his time researching s/w development methods, processes and tools
> strategies for a 1+ billion dollar IT company I know this is what we need
> and I think Maven is the perfect platform for it.
As you can see, I made some concrete proposals to reach this goal and
am currently trying to implement some kind of proof of concept that
would. But maven is a huge underdocumented beast to tame, even with
the kind support of the list.
I am currently trying to create a centralized RDF database using a
plugin (ie. not touching on maven core) but I have basic problems to
extract informations from my plugin's environment. Progress will be
slow but there seems to be more than one people interested in it so I
am eager to show something that could form the basis of a maven
component.
>
> soapbox-eof
Not sure of translation. Is this the same as "brosse à reluire" in
french ?
regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by jallen <jo...@hotmail.com>.
Arnaud Bailly-3 wrote:
>
> Hi,
> A couple of weeks ago I posted a proposal about a centralized
> reporting feature for maven that would allow easy aggregation of
> information at whatever level is needed. This proposal is centered
> around the idea of creating and maintaining a RDF database that could
> be used by plugins to find information or store information to be
> latter processed by other plugins or external tools.
>
> I am trying to implement a small proof of concept without modifying
> maven base codebase and using only plugins. I plan to do the
> following:
> 1. a base plugin to create initially the RDF database and populate it
> with basic pom's information
> 2. a modified compiler plugin to store source files structure
> information
> 3. a modified surefire plugin to store test results in the graph
> attached to the test source files and projects
> 4. a modified test report lpugin that would take advantage of the RDF
> graph to generate aggregated reports
>
Hi Arnaud,
I'm afraid I not replying to answer your questions but I am very excited
that someone is taking this on!
I've always felt that the Maven reporting system is one of its most
underleveraged features. For me the killer feature list reads: dependency
management, reporting, build lifecycle, plugin architecture and POM.
What I have found from promoting a low-cost (read open-source or cheap such
as JIRA/Confluence) ALM environment based upon Maven and Eclipse (as the
integration backbones) is that it's Mavens ability to construct a complete
project portal, snapshotted from the current source base, that has senior
management, CMMi experts and a industry luminaries alike (no names but we're
talking gang-of-four level) all 'ooh-ing' in their seats.
Information sharing, collaboration and, critically, governance reporting and
enforcement (be it tests reports, quality metrics, heuristics, plan
adherence, etc) are seen as essential if an organisation is to properly
manage its distributed and sub-contracted software development projects
(read: without there being an overworked technical lead/architect burning
midnight oil trawling through artefact repositories, running bespoke tools,
updating spreadsheets and generating management reports:))
I would like to suggest to the maven core team, and i feel cheaky saying
this as i know how busy they are and how hard they work (deseve a medal I
tell you, or at the least an IPO!) is that they properly invest in the
reporting side of things.
Currently the reporting plugins don't have the same support that build
plugins have in terms of standard Maven features (e.g. plugin configuration,
dependency managemnt) and many aspects of the reporting environment are just
not as well developed or thought out as other areas of Maven are (e.g.
hardcoded project-info reports, difficulties integrating bespoke
reports/pages into the site environment, lack of a framework to support
project measures, etc).
The development of a proper maven/apache framework to supports
report/measure execution, storage, aggregation, distribution, querying,
publication and of course site integration would result in Maven being
elevated to the place it always set out to be, project comprehension and
technical management, and really enable IT organisations to bridge the gap
between the technical disciplines (code, docs, tests) and the
managerial/governance disciplines (quality, progress, process). As someone
who spends his time researching s/w development methods, processes and tools
strategies for a 1+ billion dollar IT company I know this is what we need
and I think Maven is the perfect platform for it.
soapbox-eof
John Allen
--
View this message in context: http://www.nabble.com/Maven-central-reporting-API-tf2195661.html#a6137872
Sent from the Maven Developers forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Jimisola Laursen <li...@jimisola.com>.
Hi Arnaud,
> To delve deeper into this, I am having a hard time finding maven's big
> picture and unfortunately,
> comments in code are rather fragmentary and barely useful (when they
> exist). Is there a document on maven architecture somewhere ? Think
> the answer is no, but asking anyway :-)
First of all, I just want to say that I am (and probably a lot of others
too) very happy to see some actual work being done on aggregation of reports
:)
About documentation on Maven Architecture, we had this discussion at work
today and most of the documentation are "Howtos" or "Guides".
Document on Maven Architecture, concepts etc would be very useful.
Basically, to get an idea how things work, how they play together and so on.
If you do find something please post a link to it in this thread.
Kind regards,
Jimisola
--
View this message in context: http://www.nabble.com/Maven-central-reporting-API-tf2195661.html#a6139033
Sent from the Maven Developers forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Arnaud Bailly <ab...@oqube.com>.
Brett Porter <br...@apache.org> writes:
>> 2. How can I retrieve a mojo instance from another mojo in the same
>> or a sub project ?
>
> I think the answer is that you can't. All plugin communication is
> meant to happen through the project instance.
>
> We certainly need to find a way to make that extensible, but I'd
> suggest for now that you should be taking in XML output files that
> most plugins generate and processing them for starters.
>
That's really annoying if I want to handle aggregation properly (and
this is the whole point of what I am trying to do :-) ) What I really need is
way to climb back in the project's tree to retrieve some configuration
value of a mojo. For instance, I may have the following config:
root project (database: foo.rdf)
|
+---- project A (agg: yes, database: FooA.rdf)
|
+----- subbproject A1
+----- subbproject A2
|
+---- project B (agg: no)
+----- subbproject B1
+----- subbproject B2
When I am executing mojo for project B2, I want to retrieve RDF
database for root. But in A1, I need database FooA.
I maybe could do it using the MavenProject object but I could not
share database instance and that will lead to really messy code I
think.
> I have seen some people think about it from time to time, but not in
> any detail. Definitely worth investigating, particularly as a way of
> reviewing how we handle the lifecycle concurrency issues.
To delve deeper into this, I am having a hard time finding maven's big picture and unfortunately,
comments in code are rather fragmentary and barely useful (when they
exist). Is there a document on maven architecture somewhere ? Think
the answer is no, but asking anyway :-)
Thx for your reply,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Brett Porter <br...@apache.org>.
On 31/08/2006, at 7:44 PM, Arnaud Bailly wrote:
> Questions (which may be trivial) are:
> 1. Is there one mojo instance for each project in the hierarchy ? I
> think this is the case but I am not sure.
The mojo is instantiated every time it is run (so yes, per project,
but also per execution per project).
> 2. How can I retrieve a mojo instance from another mojo in the same
> or a sub project ?
I think the answer is that you can't. All plugin communication is
meant to happen through the project instance.
We certainly need to find a way to make that extensible, but I'd
suggest for now that you should be taking in XML output files that
most plugins generate and processing them for starters.
>
> The various POM's ingredients describes either:
> 1. data *values*, to be later processed by *functions*: File path
> settings, configuration options, project's id card all fall into
> this case. These values are organized in a tree such that one can
> refer to variable's values using dotted notation (eg.
> =foo.bar.baz=)
> 2. *functions* that process the project's data, that is essentially
> plugins (essentiallye mojos), which may themselves be
> parameterized by some more
> data or values.
Yes, I identified this mix as an issue some time back and we've only
really half talked about it and how it will be addressed. If we get
some momentum on 2.1 design tasks at any point I'll certainly push it
forward again (you can see that in the archives by searching for POM
inheritance).
>
> Thinking that way, one can imagine doing the following things:
> - provide a non-XML language layer tha would allow expressing a build
> process in an easier to use form than what is actually available
> - compile the build program for:
> - optimizing the build time
> - eventually detecting concurrency pattern such that distributed
> execution (eg. using compile farms) coul be provided
>
> Is this plain scrap or has someone else already thought about doing
> that kind of things ?
I have seen some people think about it from time to time, but not in
any detail. Definitely worth investigating, particularly as a way of
reviewing how we handle the lifecycle concurrency issues.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Jason Dillon <ja...@planet57.com>.
OMG I'm drooling... if I could get build/module data into pentaho
automatically when mvn runs... i might wet myself.
8-]
--jason
On Sep 6, 2006, at 9:50 AM, John Allen wrote:
> Whenever I sit down and thinking properly about this space I always
> end up
> thinking about business intelligence (BI). The company I work for
> has an
> overwhelming requirement for large scale project measurement and
> reporting
> and the problems that need to be addressed are the same one that BI
> attempts
> to provide for. Way back when there was a @dev discussion about
> using a
> backend DB to store measures accrued through maven plugins and an
> API to
> slice and dice that data and represent it in pretty maven site
> style reports
> (Vincent me thinks, pages should still be codehaus confluence).
>
> However this approach adds a new independent repository and a whole
> bunch of
> complexity to the very clean maven world (I love my 'and here I delete
> everything and watch maven reconstitute the entire environment as
> part of
> the build' bit of my demos). I love the wagon and I would like to
> use the
> maven repository/artifact system wherever possible but for this
> requirement
> I feel it is just not going to fly.
>
> Note: I should caveat that a bit, simple trend and snapshot data
> could be
> stored in the repository, it could even be in the form of a
> database style
> data source such as hibernate data files and that could be
> processed but my
> point is that if I have 500 projects over 4 years that’s a lot of
> data. It
> will need to be centralized and require OLAP like processing for
> its real
> value to be leveraged.
>
> Also, when you start thinking about the sorts of data you'll mine and
> present you very quickly come up with the need for some good
> visualization
> techniques such as dashboards and drill-down supporting aggregation
> reports.
> This kind of reporting UI requires something a bit more
> sophisticated than
> flat HTML (for instance the JIRA changes report is there as simple eye
> candy, you immediately click through to the wonders of JIRA when
> trying to
> analyze or interpret the data). Anyway, again we're back into BI
> space (or
> at least the persist, analyze, report space).
>
> However, in ALM the demos I've been giving recently I actually pull up
> xradar's demo pages and use that to illustrate how a this
> information *will*
> be pulled together into an overall dashboard and reporting system
> that will
> enable project oversight and health checks to be performed, I even
> go as far
> as to say we will have a maven dashboard, and here I am thinking
> directly of
> the xradar approach, just not using XSLT and vector graphics. What
> we want,
> and I say we as in my company, is something much more like JIRA in
> terms of
> its visual and functional richness but sat in the maven site world.
>
> But no I haven’t sussed how to get that in a pure maven solution
> yet. It's
> easy enough to use some JFreeChart stuff and render some maven site
> friendly
> pages (hmm, is it in the doxia world?) but the work of storing,
> processing
> and returning the data is, for us, for now, going to be handled by
> a hand
> cranked metrics database (90% done) and an open-source OLAP/BI
> solution
> (http://www.pentaho.org/). We are then going to implement
> harvesters that
> will take data from the various data sources, of which maven is
> obviously
> one (checkstyle, PMD, surefire, clover/cobertura, ...), along with
> others
> such as our build service (quickbuild/anthill/continuum), JIRA,
> confluence,
> DOORS, and other propriety business systems.
>
> I am hoping that my work on Pentaho will provide a means to bridge
> the two
> worlds. For us the maven site *is* the project portal, it’s a
> context aware
> (module/sub-project/code) reporting and service gateway (i.e. links
> into
> fisheye, jira, confluence, forums, mailing lists, SCM, etc). So
> whatever we
> do with this BI stuff I will be developing a front end to it that
> sits in
> the maven site. Once this is done I would hope to be able to find a
> way to
> use our maven dashboard and reports functionality against a
> simpler, POM
> configured backend store of some kind based upon the maven repository
> environment. I said hope didn’t I?
>
> Glad it's an area everyone's thinking about though... :)
>
> John Allen
>
> -----Original Message-----
> From: Arnaud Bailly [mailto:abailly@oqube.com]
> Sent: 06 September 2006 16:24
> To: Maven Developers List
> Subject: Re: Maven central reporting API
>
> Jason van Zyl <ja...@maven.org> writes:
>
>>
>> I was just commenting on the use of XML. If I were to design a pure
>> reporting Data API I would probably not use XML at all. I would
>> probably use find a format that would provide the fastest data
>> processing capabilities because I would like real-time reporting.
>
> RDF is just W3C buzz word for directed labelled graphs. Objects
> naturally form directed (labelled) graphs. Hence it seems natural to
> use the normalized query and representation (N3 and XML) of RDF to
> represent OO data structures.
>
>>
>> very useful, but I would still like to come up with a Data API that
>> would provide a canonical format for data that could be consumed by a
>> reporting system we came up with. Maybe that's too much to do with
>
> I totally agree with you. RDF is just a way to store and query data
> but everything is wrapped into an API for use by plugins and
> reporters. That's why I think the xradar solution is a pis-aller as we
> say in french.
>
>> limited resources but that's the idea I had. I think in the short
>> term if we're going to use everything that exists then I think XRadar
>> is the most complete, well thought out solution that is ready for use
>> right now.
>>
>
> OK. I am ready to try discussing with xradar team and maybe come up
> with a midway satisfying solution. Could you please contact them ?
>
> regards,
>
> --
> OQube < software engineering \ génie logiciel >
> Arnaud Bailly, Dr.
> \web> http://www.oqube.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: Maven central reporting API
Posted by John Allen <jo...@hotmail.com>.
Whenever I sit down and thinking properly about this space I always end up
thinking about business intelligence (BI). The company I work for has an
overwhelming requirement for large scale project measurement and reporting
and the problems that need to be addressed are the same one that BI attempts
to provide for. Way back when there was a @dev discussion about using a
backend DB to store measures accrued through maven plugins and an API to
slice and dice that data and represent it in pretty maven site style reports
(Vincent me thinks, pages should still be codehaus confluence).
However this approach adds a new independent repository and a whole bunch of
complexity to the very clean maven world (I love my 'and here I delete
everything and watch maven reconstitute the entire environment as part of
the build' bit of my demos). I love the wagon and I would like to use the
maven repository/artifact system wherever possible but for this requirement
I feel it is just not going to fly.
Note: I should caveat that a bit, simple trend and snapshot data could be
stored in the repository, it could even be in the form of a database style
data source such as hibernate data files and that could be processed but my
point is that if I have 500 projects over 4 years thats a lot of data. It
will need to be centralized and require OLAP like processing for its real
value to be leveraged.
Also, when you start thinking about the sorts of data you'll mine and
present you very quickly come up with the need for some good visualization
techniques such as dashboards and drill-down supporting aggregation reports.
This kind of reporting UI requires something a bit more sophisticated than
flat HTML (for instance the JIRA changes report is there as simple eye
candy, you immediately click through to the wonders of JIRA when trying to
analyze or interpret the data). Anyway, again we're back into BI space (or
at least the persist, analyze, report space).
However, in ALM the demos I've been giving recently I actually pull up
xradar's demo pages and use that to illustrate how a this information *will*
be pulled together into an overall dashboard and reporting system that will
enable project oversight and health checks to be performed, I even go as far
as to say we will have a maven dashboard, and here I am thinking directly of
the xradar approach, just not using XSLT and vector graphics. What we want,
and I say we as in my company, is something much more like JIRA in terms of
its visual and functional richness but sat in the maven site world.
But no I havent sussed how to get that in a pure maven solution yet. It's
easy enough to use some JFreeChart stuff and render some maven site friendly
pages (hmm, is it in the doxia world?) but the work of storing, processing
and returning the data is, for us, for now, going to be handled by a hand
cranked metrics database (90% done) and an open-source OLAP/BI solution
(http://www.pentaho.org/). We are then going to implement harvesters that
will take data from the various data sources, of which maven is obviously
one (checkstyle, PMD, surefire, clover/cobertura, ...), along with others
such as our build service (quickbuild/anthill/continuum), JIRA, confluence,
DOORS, and other propriety business systems.
I am hoping that my work on Pentaho will provide a means to bridge the two
worlds. For us the maven site *is* the project portal, its a context aware
(module/sub-project/code) reporting and service gateway (i.e. links into
fisheye, jira, confluence, forums, mailing lists, SCM, etc). So whatever we
do with this BI stuff I will be developing a front end to it that sits in
the maven site. Once this is done I would hope to be able to find a way to
use our maven dashboard and reports functionality against a simpler, POM
configured backend store of some kind based upon the maven repository
environment. I said hope didnt I?
Glad it's an area everyone's thinking about though... :)
John Allen
-----Original Message-----
From: Arnaud Bailly [mailto:abailly@oqube.com]
Sent: 06 September 2006 16:24
To: Maven Developers List
Subject: Re: Maven central reporting API
Jason van Zyl <ja...@maven.org> writes:
>
> I was just commenting on the use of XML. If I were to design a pure
> reporting Data API I would probably not use XML at all. I would
> probably use find a format that would provide the fastest data
> processing capabilities because I would like real-time reporting.
RDF is just W3C buzz word for directed labelled graphs. Objects
naturally form directed (labelled) graphs. Hence it seems natural to
use the normalized query and representation (N3 and XML) of RDF to
represent OO data structures.
>
> very useful, but I would still like to come up with a Data API that
> would provide a canonical format for data that could be consumed by a
> reporting system we came up with. Maybe that's too much to do with
I totally agree with you. RDF is just a way to store and query data
but everything is wrapped into an API for use by plugins and
reporters. That's why I think the xradar solution is a pis-aller as we
say in french.
> limited resources but that's the idea I had. I think in the short
> term if we're going to use everything that exists then I think XRadar
> is the most complete, well thought out solution that is ready for use
> right now.
>
OK. I am ready to try discussing with xradar team and maybe come up
with a midway satisfying solution. Could you please contact them ?
regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Arnaud Bailly <ab...@oqube.com>.
Jason van Zyl <ja...@maven.org> writes:
>
> I was just commenting on the use of XML. If I were to design a pure
> reporting Data API I would probably not use XML at all. I would
> probably use find a format that would provide the fastest data
> processing capabilities because I would like real-time reporting.
RDF is just W3C buzz word for directed labelled graphs. Objects
naturally form directed (labelled) graphs. Hence it seems natural to
use the normalized query and representation (N3 and XML) of RDF to
represent OO data structures.
>
> very useful, but I would still like to come up with a Data API that
> would provide a canonical format for data that could be consumed by a
> reporting system we came up with. Maybe that's too much to do with
I totally agree with you. RDF is just a way to store and query data
but everything is wrapped into an API for use by plugins and
reporters. That's why I think the xradar solution is a pis-aller as we
say in french.
> limited resources but that's the idea I had. I think in the short
> term if we're going to use everything that exists then I think XRadar
> is the most complete, well thought out solution that is ready for use
> right now.
>
OK. I am ready to try discussing with xradar team and maybe come up
with a midway satisfying solution. Could you please contact them ?
regards,
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Jason van Zyl <ja...@maven.org>.
On 6 Sep 06, at 9:39 AM 6 Sep 06, Arnaud Bailly wrote:
> Jason van Zyl <ja...@maven.org> writes:
>
>>
>> http://xradar.sourceforge.net/
>>
>
> Thank you for the pointer, really interesting tool. This is not the
> kind of thing I was thinking about but it might be an alternative,
> with the obvious advantage of existing :-) BTW, I am not sure using a
> RDF database is slower than working with XML files and XLT tranforms.
>
I was just commenting on the use of XML. If I were to design a pure
reporting Data API I would probably not use XML at all. I would
probably use find a format that would provide the fastest data
processing capabilities because I would like real-time reporting.
> You seem to know or have already been in touch with the people
> developing it. What about getting in touch with them and starting a
> real project that would incorporate xradar into maven process ? I
> am ready to become involved in this project even without leading it
> :-) I feel my vision and xradar's one are the same so let's try it
> that way.
I chatted with the guy in charge of the project in Norway so I can
try to get him to pop in here and give you a better description of
the project. XRadar is really concerned with collecting data from any
source and effectively normalizing it for coherent analysis. That is
very useful, but I would still like to come up with a Data API that
would provide a canonical format for data that could be consumed by a
reporting system we came up with. Maybe that's too much to do with
limited resources but that's the idea I had. I think in the short
term if we're going to use everything that exists then I think XRadar
is the most complete, well thought out solution that is ready for use
right now.
>
>
> --
> OQube < software engineering \ génie logiciel >
> Arnaud Bailly, Dr.
> \web> http://www.oqube.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Arnaud Bailly <ab...@oqube.com>.
Jason van Zyl <ja...@maven.org> writes:
>
> http://xradar.sourceforge.net/
>
Thank you for the pointer, really interesting tool. This is not the
kind of thing I was thinking about but it might be an alternative,
with the obvious advantage of existing :-) BTW, I am not sure using a
RDF database is slower than working with XML files and XLT tranforms.
You seem to know or have already been in touch with the people
developing it. What about getting in touch with them and starting a
real project that would incorporate xradar into maven process ? I
am ready to become involved in this project even without leading it
:-) I feel my vision and xradar's one are the same so let's try it
that way.
--
OQube < software engineering \ génie logiciel >
Arnaud Bailly, Dr.
\web> http://www.oqube.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Jason van Zyl <ja...@maven.org>.
On 6 Sep 06, at 3:02 AM 6 Sep 06, Jason Dillon wrote:
> On 8/31/06, Arnaud Bailly <ab...@oqube.com> wrote:
>> 1. a base plugin to create initially the RDF database and
>> populate it
>> with basic pom's information
>> 2. a modified compiler plugin to store source files structure
>> information
>> 3. a modified surefire plugin to store test results in the graph
>> attached to the test source files and projects
>> 4. a modified test report lpugin that would take advantage of the
>> RDF
>> graph to generate aggregated reports
>
> Why don't you implement the collection and RDF submission into a
> post-process... so that you don't need to modify existing plugins, but
> just provide RDF builders that take a plugins output (like surefire's
> xml reports) and turns that into RDF and submit it to the reporting
> server?
>
The initial idea long ago was to have a clear API reporting, we ended
up with Doxia which is a document generation API which is not quite
what we intended. I think what we're looking at here is a data api
but also a data collection api. I'm not so keen on RDF as the whole
system would probably end up being pretty slow, and if we're going to
use an XML type system then it would probably make sense to use
XRadar. It already completely works and I know the people who
developed it would love to help.
We initially wanted all the plugins to not only have Doxia sinks for
creating reports but also have a standard data sink so you could just
take a raw data and render it however you wish.
Anyway XRadar is here if we're just going to snag existing XML:
http://xradar.sourceforge.net/
Jason van Zyl
jason@maven.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Maven central reporting API
Posted by Jason Dillon <ja...@planet57.com>.
On 8/31/06, Arnaud Bailly <ab...@oqube.com> wrote:
> 1. a base plugin to create initially the RDF database and populate it
> with basic pom's information
> 2. a modified compiler plugin to store source files structure
> information
> 3. a modified surefire plugin to store test results in the graph
> attached to the test source files and projects
> 4. a modified test report lpugin that would take advantage of the RDF
> graph to generate aggregated reports
Why don't you implement the collection and RDF submission into a
post-process... so that you don't need to modify existing plugins, but
just provide RDF builders that take a plugins output (like surefire's
xml reports) and turns that into RDF and submit it to the reporting
server?
There are some folks at the Geronimo project who may be interested in
something like this too. A few of us have been talking about a
similar system to upload reports, and then a webapp to query the data
and produce nice roll up views and pretty graphs.
I spent some time pondering the idea today and it seems relatively
easy to do. A goal of the plugin would get executed from the
top-level module when the build starts, to create a ticket or
something (and capture system details and basic build intel), then
modules execute, run reports, etc, and then run a report goal, which
processes a number of configured "builders" that take the output of
previously run maven plugins and converts them into a common xml
format, and then uploads the data to the reporting server with the
ticket.
All aggregation is handled by the reporting server. Based on the
ticket and the module's pom details the server should be able to
correlate all of the modules reports and produce a roll up for that
build, and access to other builds (and roll ups of those builds) and
of course drill down into the details which were submitted, yada yada
yada.
Anyways, just some thoughts ;-)
--jason
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org