On Tue, Aug 23, 2011 at 6:14 PM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > no > > IMHO, javadoc plugin documents both reporting and build tags [1]
It's the aggregate IT in javadoc that sent me off the rails. I'm better now. > > but only reporting should be used > > and it works perfectly for Maven core 3.0.4-SNAPSHOT: really, jxr aggregate > support is fine actually when configured as reporting > > and we should promote reporting configuration only > > Regards, > > Hervé > > [1] http://maven.apache.org/plugins/maven-javadoc-plugin/examples/selective- > javadocs-report.html > > Le mardi 23 août 2011, Benson Margulies a écrit : >> On Tue, Aug 23, 2011 at 5:26 PM, Hervé BOUTEMY <herve.bout...@free.fr> > wrote: >> > I have been confused for a long time too, but finally had some >> > explanations I can try to summary here: not sure it will give every >> > answers, but at least I suppose it will help. >> >> Hervé, >> >> So far so good, and you can see that I cribbed an execute method from >> javadoc into JXR this afternoon. >> >> I have some followup qualms. executeReport is called with a Locale. >> execute is not. So, when we use execute in order to force the use of >> a particular goal, we turn off all the multi-locale support. Further, >> looks to me as if both execute and executeReport get called. In this >> 'aggregate' pattern, execute ends up with the aggregate goal, >> executeReport ends up with the plain goal. The site plugin config >> inherits down, so, contra the doc, we end up with disaggregated >> reports down below as well as the aggregated info on top. >> >> Maybe I just misunderstood the pattern in the javadoc tests; is the >> right thing to put the aggregate goal in build/plugins and nothing in >> the site plugin? But if I do that, how will the site plugin know to >> link to the report? >> >> All in all, it seems to me that the site plugin >> configuration/reportPlugins/plugin should include 'goals' in its valid >> children, so that one could run a particular goal. >> >> Or, maybe I'm just missing the point of why the move from >> configuration/aggregate to having another goal? >> >> --benson >> >> > It has to do with the difference in API between a maven plugin (execute >> > method from plugin-api [1]) and a reporting plugin (essentially generate >> > method from maven-reporting-api [2]) which is in fact a m-site-p plugin, >> > not really a Maven core plugin. >> > >> > Usually, you write a reporting plugin that is a Maven plugin too, but >> > AFAIK you can write a reporting plugin that is not a Maven plugin (I >> > didn't really tried though). >> > Usually, nobody does that because there are drawbacks: >> > - you can't define it in pluginManagement section (yes, it's not a Maven >> > plugin in this case...), >> > - maven-plugin-plugin won't generate plugin descriptor for you >> > - you won't be able to launch the report as a maven CLI invocation >> > Then usually, every reporting plugin is a build plugin too: for example, >> > even if m-project-info-report-p is announced as solely reporting plugin >> > in our plugin list, it is a build plugin too. >> > >> > When the reporting tool does not use site-descriptor+skin (javadoc, jxr, >> > surefire, ...), the execute method is quite simple then it is copied in >> > every plugin: see javadoc [3] for example >> > >> > When the reporting tool requires skin, the plugin invocation is harder: >> > maven- reporting-impl tries to implement an AbstractMavenReport class >> > [4] containing the logic for dual execution (the execute method is >> > implemented). A lot of reporting plugins extend AbstractMavenReport. >> > >> > >> > This is the summary of my understanding when I worked on >> > maven-reporting-impl and maven-reporting-api decoupling from core. >> > >> > Now the consequences on execute vs reportSets. If you intend to call >> > multiple reports when generating site, it is a site phase feature then >> > should be configured in reporting section with reportSets. Build plugins >> > are for maven CLI invocation, without site phase lifecycle binding. >> > Notice that while I'm writing this now, it's the furst time I'm really >> > understanding it :) >> > >> > Regards, >> > >> > Hervé >> > >> > [1] http://maven.apache.org/ref/current/maven-plugin-api/ >> > >> > [2] http://maven.apache.org/shared/maven-reporting-api/ >> > >> > [3] http://maven.apache.org/plugins/maven-javadoc- >> > plugin/xref/org/apache/maven/plugin/javadoc/JavadocReport.html#296 >> > >> > [4] http://maven.apache.org/shared/maven-reporting- >> > impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html >> > >> > Le mardi 23 août 2011, Benson Margulies a écrit : >> >> I am somewhat confused by the design of the site plugin with respect >> >> to adding additional goals. >> >> >> >> The new pattern is to move from 'aggregate' configuration property >> >> booleans to more goals. However, goals have to be called out in >> >> executions, and the reporting section can't spec an execution, and >> >> we're moving away from the reporting section, anyway. So now you end >> >> up with the same plugin called out as an ordinary plugin as well as in >> >> a report, and it needs an execute method that does the same thing as >> >> its executeReport, and both get called. >> >> >> >> Is there anything written down about how all this is supposed to play? >> >> Can the site plugin be told which goal to run executeReport for, or >> >> are these additional executions actually needed. >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> >> For additional commands, e-mail: dev-h...@maven.apache.org >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > For additional commands, e-mail: dev-h...@maven.apache.org >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
