Re: why does site-deploy rebuild so often?
This can also cause problems if you have, for example, ant tasks in the build (or generate-sources) phases that take a long time. Everyone of the re-do parts repeats that long build. It's not like a compile where javac doesn't recompile whatever is already compiled. I have added stuff to ant tasks (in this case, to generate java source for web service clients) so that they check whether the output of the task is already there and newer than something used to generate them. [I feel like I'm rewriting 'make' inside an ant script.] The clean will get rid of all the generated stuff and the 1st build will create it but the subsequent ones won't. It's a pain but makes the site build much more manageable. Doing this consistently lets my build finish in less memory. -- Lee On Fri, Sep 25, 2009 at 11:01 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > If you don't need the report on every module I would only specify the > report on the modules that require it. > > In this respect the section is badly let down by the lack > of a section... but that would require a schema > change... and I am not sure I see that happening any time soon... but > you could always ask Jason! ;-) > > -Stephen > > 2009/9/25 David Hoffer : > > Just a couple more ideas/questions. > > > > Currently we specify our reports at the top level only. Is there a way > to > > exclude some reports on child modules? Or should we be specifying our > > reports at each child module level where we need the report and not at > the > > top level? I.e. what's the best way to just run the minimum number of > > reports, so we use less memory? > > > > -Dave > > > > On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer > wrote: > > > >> Thanks for the explanation that makes sense. I'm surprised maven > reporting > >> is designed so poorly, I agree your approach in the invoker makes more > >> sense. > >> > >> BTW, when you say 'fork a build', is this done in the current VM? Is > there > >> a way to force all these in separate VMs? > >> > >> The problem we have is that as our build gets bigger (they never seem to > >> get smaller) we are finding that site-deploy is not reliable. Somewhere > in > >> the build it will fail, usually because its out of memory. We have > raised > >> the max heap to about 2GB, max perm gen to about 350k, etc but some > piece > >> will still fail. > >> > >> Most often it fails using the exec plugin where we need to call into > some > >> Java code. Sometimes the Flex compiler will fail. Etc. > >> > >> If we could run each of the reports in a separate VM that would solve > the > >> problem, it seems. > >> > >> What's the best approach for current users of maven to handle this? > >> > >> I suppose we could generate lots of smaller reports each on a section of > >> the build, etc, but I'd like to investigate other approaches first. > >> > >> (BTW, our CI build is on Linux.) > >> > >> -Dave > >> > >> > >> On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com> wrote: > >> > >>> 2009/9/25 David Hoffer : > >>> > Hum, > >>> > > >>> > Can you restate/finish the last point 'better still is to switch > >>> reporting > >>> > plugins to report, and not to do, and use the build lifecycle for > >>> doing'? > >>> > >>> At the moment, reporting plugins do stuff rather than just generate a > >>> report of stuff that has already been done. > >>> > >>> For example, > >>> > >>> the javadoc reporting plugin generates the javadocs... better would be > >>> to just integrate the already generated javadocs into the site. > >>> > >>> the cobertura reporting plugin measures the test coverage... better > >>> would be to just report the test coverage that was previously measured > >>> and integrate that report into the site. > >>> > >>> Thus reporting plugins would do just that: report > >>> > >>> This would keep the reporting lifecycle free from having to fork the > >>> build lifecycle in order to ensure that the latest results were > >>> available. > >>> > >>> An example of how this works is the maven-invoker-plugin version 1.4, > >>> where we added a report of the integration tests that have been run. > >>> That report never forks the build, it just reports on the previous > >>> results. > >>> > >>> With this strategy, you do the work in the build lifecycle... you > >>> report on the work previously done in the site lifecycle. > >>> > >>> > I'm not sure what you are referring to here. > >>> > > >>> > Is there a way to know if a reporting plugin is a good or bad one? > What > >>> > about the ones I'm using? I'd say the most important are cobertura, > >>> > javadocs, findbugs (not shown here). > >>> > >>> cobertura forks a build lifecycle > >>> > >>> javadocs forks a build lifecycle > >>> > >>> not sure about findbugs... but it probably forks a build lifecycle in > >>> order to ensure that all the source code folders are attached to the > >>> project model and that any generated source code is generated. >
Re: why does site-deploy rebuild so often?
If you don't need the report on every module I would only specify the report on the modules that require it. In this respect the section is badly let down by the lack of a section... but that would require a schema change... and I am not sure I see that happening any time soon... but you could always ask Jason! ;-) -Stephen 2009/9/25 David Hoffer : > Just a couple more ideas/questions. > > Currently we specify our reports at the top level only. Is there a way to > exclude some reports on child modules? Or should we be specifying our > reports at each child module level where we need the report and not at the > top level? I.e. what's the best way to just run the minimum number of > reports, so we use less memory? > > -Dave > > On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer wrote: > >> Thanks for the explanation that makes sense. I'm surprised maven reporting >> is designed so poorly, I agree your approach in the invoker makes more >> sense. >> >> BTW, when you say 'fork a build', is this done in the current VM? Is there >> a way to force all these in separate VMs? >> >> The problem we have is that as our build gets bigger (they never seem to >> get smaller) we are finding that site-deploy is not reliable. Somewhere in >> the build it will fail, usually because its out of memory. We have raised >> the max heap to about 2GB, max perm gen to about 350k, etc but some piece >> will still fail. >> >> Most often it fails using the exec plugin where we need to call into some >> Java code. Sometimes the Flex compiler will fail. Etc. >> >> If we could run each of the reports in a separate VM that would solve the >> problem, it seems. >> >> What's the best approach for current users of maven to handle this? >> >> I suppose we could generate lots of smaller reports each on a section of >> the build, etc, but I'd like to investigate other approaches first. >> >> (BTW, our CI build is on Linux.) >> >> -Dave >> >> >> On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly < >> stephen.alan.conno...@gmail.com> wrote: >> >>> 2009/9/25 David Hoffer : >>> > Hum, >>> > >>> > Can you restate/finish the last point 'better still is to switch >>> reporting >>> > plugins to report, and not to do, and use the build lifecycle for >>> doing'? >>> >>> At the moment, reporting plugins do stuff rather than just generate a >>> report of stuff that has already been done. >>> >>> For example, >>> >>> the javadoc reporting plugin generates the javadocs... better would be >>> to just integrate the already generated javadocs into the site. >>> >>> the cobertura reporting plugin measures the test coverage... better >>> would be to just report the test coverage that was previously measured >>> and integrate that report into the site. >>> >>> Thus reporting plugins would do just that: report >>> >>> This would keep the reporting lifecycle free from having to fork the >>> build lifecycle in order to ensure that the latest results were >>> available. >>> >>> An example of how this works is the maven-invoker-plugin version 1.4, >>> where we added a report of the integration tests that have been run. >>> That report never forks the build, it just reports on the previous >>> results. >>> >>> With this strategy, you do the work in the build lifecycle... you >>> report on the work previously done in the site lifecycle. >>> >>> > I'm not sure what you are referring to here. >>> > >>> > Is there a way to know if a reporting plugin is a good or bad one? What >>> > about the ones I'm using? I'd say the most important are cobertura, >>> > javadocs, findbugs (not shown here). >>> >>> cobertura forks a build lifecycle >>> >>> javadocs forks a build lifecycle >>> >>> not sure about findbugs... but it probably forks a build lifecycle in >>> order to ensure that all the source code folders are attached to the >>> project model and that any generated source code is generated. >>> >>> > >>> > See below for other comments/questions. >>> > >>> > -Dave >>> > >>> > >>> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly < >>> > stephen.alan.conno...@gmail.com> wrote: >>> > >>> >> because each of the reporting plugins have no concept of how far up the >>> >> lifecycle the build has gone >>> >> >>> >> in maven there are three (3) lifecycles: >>> >> >>> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases >>> >> >>> >> 2: the site lifecycle: pre-site, site and site-deploy >>> >> >>> >> 3. the build lifecycle: validate, ... deploy >>> >> >>> >> mojos have no way to find out which lifecycle they are running, what >>> phase >>> >> they are executing in, and what phases have already executed >>> >> >>> >> thus if you want to report the results of unit tests, you can either: >>> scan >>> >> the filesystem for the results and hope that these results are current; >>> or >>> >> you can fork a build up as far as test and then pull the results from >>> the >>> >> filesystem >>> >> >>> > >>> > [dh] Are you saying that since during reporting surefire has no way
Re: why does site-deploy rebuild so often?
Just a couple more ideas/questions. Currently we specify our reports at the top level only. Is there a way to exclude some reports on child modules? Or should we be specifying our reports at each child module level where we need the report and not at the top level? I.e. what's the best way to just run the minimum number of reports, so we use less memory? -Dave On Fri, Sep 25, 2009 at 7:06 AM, David Hoffer wrote: > Thanks for the explanation that makes sense. I'm surprised maven reporting > is designed so poorly, I agree your approach in the invoker makes more > sense. > > BTW, when you say 'fork a build', is this done in the current VM? Is there > a way to force all these in separate VMs? > > The problem we have is that as our build gets bigger (they never seem to > get smaller) we are finding that site-deploy is not reliable. Somewhere in > the build it will fail, usually because its out of memory. We have raised > the max heap to about 2GB, max perm gen to about 350k, etc but some piece > will still fail. > > Most often it fails using the exec plugin where we need to call into some > Java code. Sometimes the Flex compiler will fail. Etc. > > If we could run each of the reports in a separate VM that would solve the > problem, it seems. > > What's the best approach for current users of maven to handle this? > > I suppose we could generate lots of smaller reports each on a section of > the build, etc, but I'd like to investigate other approaches first. > > (BTW, our CI build is on Linux.) > > -Dave > > > On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> 2009/9/25 David Hoffer : >> > Hum, >> > >> > Can you restate/finish the last point 'better still is to switch >> reporting >> > plugins to report, and not to do, and use the build lifecycle for >> doing'? >> >> At the moment, reporting plugins do stuff rather than just generate a >> report of stuff that has already been done. >> >> For example, >> >> the javadoc reporting plugin generates the javadocs... better would be >> to just integrate the already generated javadocs into the site. >> >> the cobertura reporting plugin measures the test coverage... better >> would be to just report the test coverage that was previously measured >> and integrate that report into the site. >> >> Thus reporting plugins would do just that: report >> >> This would keep the reporting lifecycle free from having to fork the >> build lifecycle in order to ensure that the latest results were >> available. >> >> An example of how this works is the maven-invoker-plugin version 1.4, >> where we added a report of the integration tests that have been run. >> That report never forks the build, it just reports on the previous >> results. >> >> With this strategy, you do the work in the build lifecycle... you >> report on the work previously done in the site lifecycle. >> >> > I'm not sure what you are referring to here. >> > >> > Is there a way to know if a reporting plugin is a good or bad one? What >> > about the ones I'm using? I'd say the most important are cobertura, >> > javadocs, findbugs (not shown here). >> >> cobertura forks a build lifecycle >> >> javadocs forks a build lifecycle >> >> not sure about findbugs... but it probably forks a build lifecycle in >> order to ensure that all the source code folders are attached to the >> project model and that any generated source code is generated. >> >> > >> > See below for other comments/questions. >> > >> > -Dave >> > >> > >> > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly < >> > stephen.alan.conno...@gmail.com> wrote: >> > >> >> because each of the reporting plugins have no concept of how far up the >> >> lifecycle the build has gone >> >> >> >> in maven there are three (3) lifecycles: >> >> >> >> 1. the clean lifecycle: pre-clean, clean and post-clean phases >> >> >> >> 2: the site lifecycle: pre-site, site and site-deploy >> >> >> >> 3. the build lifecycle: validate, ... deploy >> >> >> >> mojos have no way to find out which lifecycle they are running, what >> phase >> >> they are executing in, and what phases have already executed >> >> >> >> thus if you want to report the results of unit tests, you can either: >> scan >> >> the filesystem for the results and hope that these results are current; >> or >> >> you can fork a build up as far as test and then pull the results from >> the >> >> filesystem >> >> >> > >> > [dh] Are you saying that since during reporting surefire has no way to >> know >> > if you previously did an install and thus ran the test goal, it will >> fork a >> > new build and run the build lifecycle upto test? >> >> yes >> >> > >> >> >> >> then if you want code coverage... >> >> >> >> if you want to generate javadocs, you need to fork a build up as far as >> >> process-sources in order to ensure that the source code has been >> generated >> >> before generating the javadocs >> >> >> >> if you are a good reporting plugin, you will fork the build
Re: why does site-deploy rebuild so often?
Thanks for the explanation that makes sense. I'm surprised maven reporting is designed so poorly, I agree your approach in the invoker makes more sense. BTW, when you say 'fork a build', is this done in the current VM? Is there a way to force all these in separate VMs? The problem we have is that as our build gets bigger (they never seem to get smaller) we are finding that site-deploy is not reliable. Somewhere in the build it will fail, usually because its out of memory. We have raised the max heap to about 2GB, max perm gen to about 350k, etc but some piece will still fail. Most often it fails using the exec plugin where we need to call into some Java code. Sometimes the Flex compiler will fail. Etc. If we could run each of the reports in a separate VM that would solve the problem, it seems. What's the best approach for current users of maven to handle this? I suppose we could generate lots of smaller reports each on a section of the build, etc, but I'd like to investigate other approaches first. (BTW, our CI build is on Linux.) -Dave On Fri, Sep 25, 2009 at 3:50 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > 2009/9/25 David Hoffer : > > Hum, > > > > Can you restate/finish the last point 'better still is to switch > reporting > > plugins to report, and not to do, and use the build lifecycle for doing'? > > At the moment, reporting plugins do stuff rather than just generate a > report of stuff that has already been done. > > For example, > > the javadoc reporting plugin generates the javadocs... better would be > to just integrate the already generated javadocs into the site. > > the cobertura reporting plugin measures the test coverage... better > would be to just report the test coverage that was previously measured > and integrate that report into the site. > > Thus reporting plugins would do just that: report > > This would keep the reporting lifecycle free from having to fork the > build lifecycle in order to ensure that the latest results were > available. > > An example of how this works is the maven-invoker-plugin version 1.4, > where we added a report of the integration tests that have been run. > That report never forks the build, it just reports on the previous > results. > > With this strategy, you do the work in the build lifecycle... you > report on the work previously done in the site lifecycle. > > > I'm not sure what you are referring to here. > > > > Is there a way to know if a reporting plugin is a good or bad one? What > > about the ones I'm using? I'd say the most important are cobertura, > > javadocs, findbugs (not shown here). > > cobertura forks a build lifecycle > > javadocs forks a build lifecycle > > not sure about findbugs... but it probably forks a build lifecycle in > order to ensure that all the source code folders are attached to the > project model and that any generated source code is generated. > > > > > See below for other comments/questions. > > > > -Dave > > > > > > On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > >> because each of the reporting plugins have no concept of how far up the > >> lifecycle the build has gone > >> > >> in maven there are three (3) lifecycles: > >> > >> 1. the clean lifecycle: pre-clean, clean and post-clean phases > >> > >> 2: the site lifecycle: pre-site, site and site-deploy > >> > >> 3. the build lifecycle: validate, ... deploy > >> > >> mojos have no way to find out which lifecycle they are running, what > phase > >> they are executing in, and what phases have already executed > >> > >> thus if you want to report the results of unit tests, you can either: > scan > >> the filesystem for the results and hope that these results are current; > or > >> you can fork a build up as far as test and then pull the results from > the > >> filesystem > >> > > > > [dh] Are you saying that since during reporting surefire has no way to > know > > if you previously did an install and thus ran the test goal, it will fork > a > > new build and run the build lifecycle upto test? > > yes > > > > >> > >> then if you want code coverage... > >> > >> if you want to generate javadocs, you need to fork a build up as far as > >> process-sources in order to ensure that the source code has been > generated > >> before generating the javadocs > >> > >> if you are a good reporting plugin, you will fork the build > >> non-recursive... bad plugins are aggregator plugins that fork a build > >> (everything is hunky-dory until you have two forking aggregator plugins > in > >> the same build, as they will recursively fork each other until you get > to a > >> leaf project) > >> > >> 3.x might help solve some of these issues... better still is to switch > >> reporting plugins to report, and not to do, and use the build lifecycle > for > >> doing > >> > > [dh] ?? > > > >> > >> Sent from my [rhymes with tryPod] ;-) > >> > >> > >> On 24 Sep 2009, at 22:18, David Hoffer wrote: > >> > >> We
Re: why does site-deploy rebuild so often?
2009/9/25 David Hoffer :
> Hum,
>
> Can you restate/finish the last point 'better still is to switch reporting
> plugins to report, and not to do, and use the build lifecycle for doing'?
At the moment, reporting plugins do stuff rather than just generate a
report of stuff that has already been done.
For example,
the javadoc reporting plugin generates the javadocs... better would be
to just integrate the already generated javadocs into the site.
the cobertura reporting plugin measures the test coverage... better
would be to just report the test coverage that was previously measured
and integrate that report into the site.
Thus reporting plugins would do just that: report
This would keep the reporting lifecycle free from having to fork the
build lifecycle in order to ensure that the latest results were
available.
An example of how this works is the maven-invoker-plugin version 1.4,
where we added a report of the integration tests that have been run.
That report never forks the build, it just reports on the previous
results.
With this strategy, you do the work in the build lifecycle... you
report on the work previously done in the site lifecycle.
> I'm not sure what you are referring to here.
>
> Is there a way to know if a reporting plugin is a good or bad one? What
> about the ones I'm using? I'd say the most important are cobertura,
> javadocs, findbugs (not shown here).
cobertura forks a build lifecycle
javadocs forks a build lifecycle
not sure about findbugs... but it probably forks a build lifecycle in
order to ensure that all the source code folders are attached to the
project model and that any generated source code is generated.
>
> See below for other comments/questions.
>
> -Dave
>
>
> On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> because each of the reporting plugins have no concept of how far up the
>> lifecycle the build has gone
>>
>> in maven there are three (3) lifecycles:
>>
>> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>>
>> 2: the site lifecycle: pre-site, site and site-deploy
>>
>> 3. the build lifecycle: validate, ... deploy
>>
>> mojos have no way to find out which lifecycle they are running, what phase
>> they are executing in, and what phases have already executed
>>
>> thus if you want to report the results of unit tests, you can either: scan
>> the filesystem for the results and hope that these results are current; or
>> you can fork a build up as far as test and then pull the results from the
>> filesystem
>>
>
> [dh] Are you saying that since during reporting surefire has no way to know
> if you previously did an install and thus ran the test goal, it will fork a
> new build and run the build lifecycle upto test?
yes
>
>>
>> then if you want code coverage...
>>
>> if you want to generate javadocs, you need to fork a build up as far as
>> process-sources in order to ensure that the source code has been generated
>> before generating the javadocs
>>
>> if you are a good reporting plugin, you will fork the build
>> non-recursive... bad plugins are aggregator plugins that fork a build
>> (everything is hunky-dory until you have two forking aggregator plugins in
>> the same build, as they will recursively fork each other until you get to a
>> leaf project)
>>
>> 3.x might help solve some of these issues... better still is to switch
>> reporting plugins to report, and not to do, and use the build lifecycle for
>> doing
>>
> [dh] ??
>
>>
>> Sent from my [rhymes with tryPod] ;-)
>>
>>
>> On 24 Sep 2009, at 22:18, David Hoffer wrote:
>>
>> We keep having problems with our site-deploy build either hanging or
>>> running
>>> out of memory. I just noticed that it rebuilds everything about 11 times!
>>> Why?
>>>
>>> (This top level pom has 3 modules where those 3 modules each have a few
>>> modules. This is the only pom with a reporting section.)
>>>
>>> Here is our top level reporting section.
>>>
>>>
>>>
>>>
>>> org.codehaus.mojo
>>> javancss-maven-plugin
>>> 2.0-beta-2
>>>
>>>
>>> org.codehaus.mojo
>>> cobertura-maven-plugin
>>> ${cobertura-maven-plugin.version}
>>>
>>>
>>> org.codehaus.mojo
>>> surefire-report-maven-plugin
>>> 2.0-beta-1
>>>
>>>
>>>
>>> org.apache.maven.plugins
>>> maven-source-plugin
>>> ${maven-source-plugin.version}
>>>
>>>
>>> org.apache.maven.plugins
>>> maven-javadoc-plugin
>>> ${maven-javadoc-plugin.version}
>>>
>>> true
>>>
>>>
>>>
>>> org.codehaus.mojo
>>> jxr-maven-plugin
>>> 2.0-beta-1
>>>
>>>
>>> o
Re: why does site-deploy rebuild so often?
Hum,
Can you restate/finish the last point 'better still is to switch reporting
plugins to report, and not to do, and use the build lifecycle for doing'?
I'm not sure what you are referring to here.
Is there a way to know if a reporting plugin is a good or bad one? What
about the ones I'm using? I'd say the most important are cobertura,
javadocs, findbugs (not shown here).
See below for other comments/questions.
-Dave
On Thu, Sep 24, 2009 at 3:33 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
> because each of the reporting plugins have no concept of how far up the
> lifecycle the build has gone
>
> in maven there are three (3) lifecycles:
>
> 1. the clean lifecycle: pre-clean, clean and post-clean phases
>
> 2: the site lifecycle: pre-site, site and site-deploy
>
> 3. the build lifecycle: validate, ... deploy
>
> mojos have no way to find out which lifecycle they are running, what phase
> they are executing in, and what phases have already executed
>
> thus if you want to report the results of unit tests, you can either: scan
> the filesystem for the results and hope that these results are current; or
> you can fork a build up as far as test and then pull the results from the
> filesystem
>
[dh] Are you saying that since during reporting surefire has no way to know
if you previously did an install and thus ran the test goal, it will fork a
new build and run the build lifecycle upto test?
>
> then if you want code coverage...
>
> if you want to generate javadocs, you need to fork a build up as far as
> process-sources in order to ensure that the source code has been generated
> before generating the javadocs
>
> if you are a good reporting plugin, you will fork the build
> non-recursive... bad plugins are aggregator plugins that fork a build
> (everything is hunky-dory until you have two forking aggregator plugins in
> the same build, as they will recursively fork each other until you get to a
> leaf project)
>
> 3.x might help solve some of these issues... better still is to switch
> reporting plugins to report, and not to do, and use the build lifecycle for
> doing
>
[dh] ??
>
> Sent from my [rhymes with tryPod] ;-)
>
>
> On 24 Sep 2009, at 22:18, David Hoffer wrote:
>
> We keep having problems with our site-deploy build either hanging or
>> running
>> out of memory. I just noticed that it rebuilds everything about 11 times!
>> Why?
>>
>> (This top level pom has 3 modules where those 3 modules each have a few
>> modules. This is the only pom with a reporting section.)
>>
>> Here is our top level reporting section.
>>
>>
>>
>>
>> org.codehaus.mojo
>> javancss-maven-plugin
>> 2.0-beta-2
>>
>>
>> org.codehaus.mojo
>> cobertura-maven-plugin
>> ${cobertura-maven-plugin.version}
>>
>>
>> org.codehaus.mojo
>> surefire-report-maven-plugin
>> 2.0-beta-1
>>
>>
>>
>> org.apache.maven.plugins
>> maven-source-plugin
>> ${maven-source-plugin.version}
>>
>>
>> org.apache.maven.plugins
>> maven-javadoc-plugin
>> ${maven-javadoc-plugin.version}
>>
>> true
>>
>>
>>
>> org.codehaus.mojo
>> jxr-maven-plugin
>> 2.0-beta-1
>>
>>
>> org.apache.maven.plugins
>> maven-pmd-plugin
>> 2.4
>>
>> ${jdkVersion}
>>
>> /rulesets/basic.xml
>>
>> xml
>> true
>> utf-8
>> 100
>>
>>
>>
>> org.apache.maven.plugins
>> maven-project-info-reports-plugin
>> 2.1.1
>>
>>
>>
>> dependencies
>> dependency-convergence
>> project-team
>> cim
>> license
>> scm
>> index
>> summary
>>
>>
>>
>>
>>
>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>
Re: why does site-deploy rebuild so often?
because each of the reporting plugins have no concept of how far up
the lifecycle the build has gone
in maven there are three (3) lifecycles:
1. the clean lifecycle: pre-clean, clean and post-clean phases
2: the site lifecycle: pre-site, site and site-deploy
3. the build lifecycle: validate, ... deploy
mojos have no way to find out which lifecycle they are running, what
phase they are executing in, and what phases have already executed
thus if you want to report the results of unit tests, you can either:
scan the filesystem for the results and hope that these results are
current; or you can fork a build up as far as test and then pull the
results from the filesystem
then if you want code coverage...
if you want to generate javadocs, you need to fork a build up as far
as process-sources in order to ensure that the source code has been
generated before generating the javadocs
if you are a good reporting plugin, you will fork the build non-
recursive... bad plugins are aggregator plugins that fork a build
(everything is hunky-dory until you have two forking aggregator
plugins in the same build, as they will recursively fork each other
until you get to a leaf project)
3.x might help solve some of these issues... better still is to switch
reporting plugins to report, and not to do, and use the build
lifecycle for doing
Sent from my [rhymes with tryPod] ;-)
On 24 Sep 2009, at 22:18, David Hoffer wrote:
We keep having problems with our site-deploy build either hanging or
running
out of memory. I just noticed that it rebuilds everything about 11
times!
Why?
(This top level pom has 3 modules where those 3 modules each have a
few
modules. This is the only pom with a reporting section.)
Here is our top level reporting section.
org.codehaus.mojo
javancss-maven-plugin
2.0-beta-2
org.codehaus.mojo
cobertura-maven-plugin
${cobertura-maven-plugin.version}
org.codehaus.mojo
surefire-report-maven-plugin
2.0-beta-1
org.apache.maven.plugins
maven-source-plugin
${maven-source-plugin.version}
org.apache.maven.plugins
maven-javadoc-plugin
${maven-javadoc-plugin.version}
true
org.codehaus.mojo
jxr-maven-plugin
2.0-beta-1
org.apache.maven.plugins
maven-pmd-plugin
2.4
${jdkVersion}
/rulesets/basic.xml
xml
true
utf-8
100
org.apache.maven.plugins
maven-project-info-reports-pluginartifactId>
2.1.1
dependencies
dependency-convergence
project-team
cim
license
scm
index
summary
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
why does site-deploy rebuild so often?
We keep having problems with our site-deploy build either hanging or running
out of memory. I just noticed that it rebuilds everything about 11 times!
Why?
(This top level pom has 3 modules where those 3 modules each have a few
modules. This is the only pom with a reporting section.)
Here is our top level reporting section.
org.codehaus.mojo
javancss-maven-plugin
2.0-beta-2
org.codehaus.mojo
cobertura-maven-plugin
${cobertura-maven-plugin.version}
org.codehaus.mojo
surefire-report-maven-plugin
2.0-beta-1
org.apache.maven.plugins
maven-source-plugin
${maven-source-plugin.version}
org.apache.maven.plugins
maven-javadoc-plugin
${maven-javadoc-plugin.version}
true
org.codehaus.mojo
jxr-maven-plugin
2.0-beta-1
org.apache.maven.plugins
maven-pmd-plugin
2.4
${jdkVersion}
/rulesets/basic.xml
xml
true
utf-8
100
org.apache.maven.plugins
maven-project-info-reports-plugin
2.1.1
dependencies
dependency-convergence
project-team
cim
license
scm
index
summary
