Request Maven 2.1 New Phase - reporting-aggregate

[Joakim Erdfelt <jo...@erdfelt.com>]

I'd like to see a discussion start on adding the possibility of a new
phase into the default lifecycle.

A reporting-aggregate that executes at the end of all standard reports.
(Could also call it post-reporting)

I can see the Dashboard Report, QA Labs, and even a standard reporting
framework utilizing this phase to perform some needed tasks.

- Joakim

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

Re: Request Maven 2.1 New Phase - reporting-aggregate

[Jason Dillon <ja...@planet57.com>]

> Maybe for consistency having:
> generate-reports (for all those that haven't executed yet)
> process-reports (could aggregate them here)
>
> ... just before the package phase? (Or maybe later, before install,  
> after integration test).
>
> I think moving more towards having these as part of a standard  
> build instead of the whole site + fork thing is the way to go, and  
> then just being able to turn them on or off as needed. The only  
> concern is whether they can make sense concurrently sometimes  
> (especially your code coverage ones that mangle the class files :)

+1

These would be good additions to the standard set of phases IMO.

--jason


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

Re: Request Maven 2.1 New Phase - reporting-aggregate

[Mykel Alvis <my...@weirdness.com>]

I'm interested in this, as well.  I'm being asked to provide aggregation
across several reports (although nobody seems to be able to tell me exactly
what I'm aggregating just yet.. :) )

On 1/31/07, dvicente <dv...@gmail.com> wrote:
>
>
> it's my problem with the dashboard-maven-plugin.
>
> i must include the dashboard-maven-plugin in reporting section but i must
> do
> "mvn site" to let each report generates their report and after do a "mvn
> dashboard-report:dashboard" to aggregate all reports.
>
> with that, I lose the site's integration of my report.
>
> +1 for me
>
>
>
> brettporter wrote:
> >
> > I think that makes sense. I wouldn't go with post-reporting, though,
> > as there is no 'reporting' phase - they happen when it's appropriate
> > (process-sources, test, etc).
> >
> > Maybe for consistency having:
> > generate-reports (for all those that haven't executed yet)
> > process-reports (could aggregate them here)
> >
> > ... just before the package phase? (Or maybe later, before install,
> > after integration test).
> >
> > I think moving more towards having these as part of a standard build
> > instead of the whole site + fork thing is the way to go, and then
> > just being able to turn them on or off as needed. The only concern is
> > whether they can make sense concurrently sometimes (especially your
> > code coverage ones that mangle the class files :)
> >
> > Cheers,
> > Brett
> >
> > On 31/01/2007, at 9:38 AM, Joakim Erdfelt wrote:
> >
> >> I'd like to see a discussion start on adding the possibility of a new
> >> phase into the default lifecycle.
> >>
> >> A reporting-aggregate that executes at the end of all standard
> >> reports.
> >> (Could also call it post-reporting)
> >>
> >> I can see the Dashboard Report, QA Labs, and even a standard reporting
> >> framework utilizing this phase to perform some needed tasks.
> >>
> >> - Joakim
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Request-Maven-2.1-New-Phase---reporting-aggregate-tf3145437s177.html#a8731614
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
I'm just an unfrozen caveman software developer.  I don't understand your
strange, "modern" ways.

Re: Request Maven 2.1 New Phase - reporting-aggregate

[dvicente <dv...@gmail.com>]

it's my problem with the dashboard-maven-plugin.

i must include the dashboard-maven-plugin in reporting section but i must do
"mvn site" to let each report generates their report and after do a "mvn
dashboard-report:dashboard" to aggregate all reports.

with that, I lose the site's integration of my report.

+1 for me



brettporter wrote:
> 
> I think that makes sense. I wouldn't go with post-reporting, though,  
> as there is no 'reporting' phase - they happen when it's appropriate  
> (process-sources, test, etc).
> 
> Maybe for consistency having:
> generate-reports (for all those that haven't executed yet)
> process-reports (could aggregate them here)
> 
> ... just before the package phase? (Or maybe later, before install,  
> after integration test).
> 
> I think moving more towards having these as part of a standard build  
> instead of the whole site + fork thing is the way to go, and then  
> just being able to turn them on or off as needed. The only concern is  
> whether they can make sense concurrently sometimes (especially your  
> code coverage ones that mangle the class files :)
> 
> Cheers,
> Brett
> 
> On 31/01/2007, at 9:38 AM, Joakim Erdfelt wrote:
> 
>> I'd like to see a discussion start on adding the possibility of a new
>> phase into the default lifecycle.
>>
>> A reporting-aggregate that executes at the end of all standard  
>> reports.
>> (Could also call it post-reporting)
>>
>> I can see the Dashboard Report, QA Labs, and even a standard reporting
>> framework utilizing this phase to perform some needed tasks.
>>
>> - Joakim
>>
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Request-Maven-2.1-New-Phase---reporting-aggregate-tf3145437s177.html#a8731614
Sent from the Maven Developers mailing list archive at Nabble.com.


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

Re: Request Maven 2.1 New Phase - reporting-aggregate

[Franz Allan Valencia See <fr...@gmail.com>]

Good day,

* What would be the main difference between the reporting phase(s) and
the site phases? the former are for reports while the latter are for
the documentation? What about reports about the documentation?
* As for when, maybe it should be before packaging so that users will
have the option to package the report as well ( if they need to do so
). But if there would be reports that run on the assemblies, then this
would not work.

Just my 2 cents worth :-)
- Franz

On 1/30/07, Brett Porter <br...@apache.org> wrote:
> I think that makes sense. I wouldn't go with post-reporting, though,
> as there is no 'reporting' phase - they happen when it's appropriate
> (process-sources, test, etc).
>
> Maybe for consistency having:
> generate-reports (for all those that haven't executed yet)
> process-reports (could aggregate them here)
>
> ... just before the package phase? (Or maybe later, before install,
> after integration test).
>
> I think moving more towards having these as part of a standard build
> instead of the whole site + fork thing is the way to go, and then
> just being able to turn them on or off as needed. The only concern is
> whether they can make sense concurrently sometimes (especially your
> code coverage ones that mangle the class files :)
>
> Cheers,
> Brett
>
> On 31/01/2007, at 9:38 AM, Joakim Erdfelt wrote:
>
> > I'd like to see a discussion start on adding the possibility of a new
> > phase into the default lifecycle.
> >
> > A reporting-aggregate that executes at the end of all standard
> > reports.
> > (Could also call it post-reporting)
> >
> > I can see the Dashboard Report, QA Labs, and even a standard reporting
> > framework utilizing this phase to perform some needed tasks.
> >
> > - Joakim
> >
> > ---------------------------------------------------------------------
> > 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: Request Maven 2.1 New Phase - reporting-aggregate

[Brett Porter <br...@apache.org>]

I think that makes sense. I wouldn't go with post-reporting, though,  
as there is no 'reporting' phase - they happen when it's appropriate  
(process-sources, test, etc).

Maybe for consistency having:
generate-reports (for all those that haven't executed yet)
process-reports (could aggregate them here)

... just before the package phase? (Or maybe later, before install,  
after integration test).

I think moving more towards having these as part of a standard build  
instead of the whole site + fork thing is the way to go, and then  
just being able to turn them on or off as needed. The only concern is  
whether they can make sense concurrently sometimes (especially your  
code coverage ones that mangle the class files :)

Cheers,
Brett

On 31/01/2007, at 9:38 AM, Joakim Erdfelt wrote:

> I'd like to see a discussion start on adding the possibility of a new
> phase into the default lifecycle.
>
> A reporting-aggregate that executes at the end of all standard  
> reports.
> (Could also call it post-reporting)
>
> I can see the Dashboard Report, QA Labs, and even a standard reporting
> framework utilizing this phase to perform some needed tasks.
>
> - Joakim
>
> ---------------------------------------------------------------------
> 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: Request Maven 2.1 New Phase - reporting-aggregate

[Jason van Zyl <ja...@maven.org>]

On 30 Jan 07, at 2:38 PM 30 Jan 07, Joakim Erdfelt wrote:

> I'd like to see a discussion start on adding the possibility of a new
> phase into the default lifecycle.
>

You mean the default build lifecyle or the site lifecycle?

Jason.

> A reporting-aggregate that executes at the end of all standard  
> reports.
> (Could also call it post-reporting)
>
> I can see the Dashboard Report, QA Labs, and even a standard reporting
> framework utilizing this phase to perform some needed tasks.
>
> - Joakim
>
> ---------------------------------------------------------------------
> 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