To summarize for any future thread readers... Right now, the site plugin, and its related report plugins, are highly unlikely to work reliably for any non-standard project layout (and I personally haven't tried a layout that does work).
If you have just one extra layer between your parent/aggregator and your children, then the project-info plugin breaks. https://jira.codehaus.org/browse/MPIR-279 If you have an aggregator at the root and a child below, then the site plugin breaks. https://jira.codehaus.org/browse/MSITE-691 It also clobbers the target directory when using site:stage (Was reported under http://jira.codehaus.org/browse/MSITE-690, but a JIRA bug has created two issues with the same id MSITE-690) The topSiteURL parameter mentioned below had no effect in fixing site:stage. The Javadoc plugin runs the validate and generate-sources phases when it shoudn't slowing down (and potentially generating incorrect) docs. https://jira.codehaus.org/browse/MJAVADOC-369 The Javadoc plugin has performance/invocation problems meaning that it takes longer and longer the more modules you have as it keeps on repeating the same tasks. http://jira.codehaus.org/browse/MJAVADOC-171 (or similar) Figuring out a suitable set of configuration to generate aggregate reports in the aggregate location and leaf reports in the leaf location is hard, as the documentation is weak. While some plugins just seem to work (checkstyle), others do not. Configuring the report sets to avoid the undesired test-jxr and test-javadoc causes the aggregates to stop working. The reporting plugins generate incomplete HTML files that have to be processed by the site plugin before they are readable (to handle ${} interpolations and css). Yet, there is no way to run that site plugin processing without running the rest of the broken site tasks. The site plugin needs a new goal. http://jira.codehaus.org/browse/MSITE-690 I ended up replacing the index.html and site.xml to avoid the broken links from MPIR-279 and MSITE-691. I then generated only the aggregate level docs, producing nothing at the child level, avoiding some of the slow performance. While some of my emails may appear negative, it is my opinion that site and reporting in Maven is not currently suitable for general use. thanks Stephen On 1 June 2013 12:05, Stephen Colebourne <scolebou...@joda.org> wrote: > On 1 June 2013 08:30, Hervé BOUTEMY <herve.bout...@free.fr> wrote: >> yes, I worked recently on this exact issue: site *staging* on complex cases >> like yours, which is not as usual as you expect >> It took me a good number of hours with the issue reporter to understand what >> he was doing, what he was expecting that wasn't trivial, and I found a >> solution with this topSiteURL > > Thanks for looking into it. Part of the problem with these things is > that it take 90 minutes to run the site plugin. Thats because of the > repeated invocation of the same goals, similar to > http://jira.codehaus.org/browse/MJAVADOC-286 and related issues. I > think there is still a more general problem with multi-modules sites. > > Anyway, I will try to topSiteURL property next week. > > 4 issues raised in total now ;-) > Stephen --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
