Hi Nicolas, This sounds very similar to the dashboard plugin. Why don't we work all together to improve it? For example, you're interested in CSV extracts. That's a good idea and this feature can be very easily added to the dashboard plugin.
Is there anything that you have in the system you're building that you cannot find in the dashboard plugin? Thanks -Vincent > -----Original Message----- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: 06 May 2004 17:39 > To: Maven Developers List > Subject: Re: plugin to gather statistics, make a summary and store > themintoaDB > > > Here's what we are trying to build (sorry, cannot share : business use !) > > Our plugin acts as a postgoal to site. It use itself plugable parsers for > reports. Each parser (digester based) tries to > extract max infos from associated xdoc report. > > For each report, indicator classes are used to extract some interesting > (*) datas from parser > datas (*: interesting to be defined by project managers !) > > The plugin extract all indicators needed on a project based on its > configuration file and saves it in a xml timestamped > "report". > > It then loads all reports (history) and builds a Excel sheet with those > datas. The sheet has macros to build history > diagrams (example : "number of checkstyle warnings / line of code"). > > This way, project manager should get an excel report on project state and > history. > > Nico. > > > > On Wed, 2004-05-05 at 02:47, Nicolas De Loof wrote: > > > I was thinking about something like this. > > > I vas trying to build a plugin that should as a "site" postGoal > > > It works this way: > > > > > > For ecah "*-report.xml" file in target/generated-doc it search a > coresponding > > > stylesheet (jsl in plugin-resources) and applies it. > > > It then concat the result of all those stylesheets to a merged- > repport.xml that could > > > be formated by xdoc and becomes the project summary on the site. It > couls also be saved > > > as timestamp or in DB. > > > > My only problem with that is the you probably need a different parser > for each report. > > The plugin may know in a better way how to extract the relevant > information. So I would perhaps rather have the > functionality to extract the info in each plugin, or at least make it > possible to be there. > > The drawback with that are: > > - no centralization for information extraction > > - the plugin defines what is extracted. Each users may want different > info. > > > > I would really appreciate some input/thoughts from the people who are > working more on the core, such as Jason or > Vincent. > > > > Jerome > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > Our name has changed, please update your address book to the following > format for the latest identities received "[EMAIL PROTECTED]". > > This message contains information that may be privileged or confidential > and is the property of the Capgemini Group. It is intended only for the > person to whom it is addressed. If you are not the intended recipient, > you are not authorized to read, print, retain, copy, disseminate, > distribute, or use this message or any part thereof. If you receive this > message in error, please notify the sender immediately and delete all > copies of this message. > > > --------------------------------------------------------------------- > 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]
