Hi Stephen,

You seem like a very smart guy, but your mails come off very negatively.
Have you heard of the "praise sandwich"? It helps make harsh criticism less
painful. Your mails are the opposite of that, reading something like:

  Hi,
  You suck.
  I have all these problems. How can I fix them?
  P.S. You suck.

I know it's frustrating trying to figure out some of Maven's crap -- I
really do. And I agree about the documentation being really bad and/or out
of date in a lot of places. But it is a complex system that is developed by
an OSS community, so that is rather par for the course, even for otherwise
good systems. (OK, Maven's is worse than usual, but is also has a lot to
document...)

Anyway, I decided to stop answering you on the lists because your mails
annoyed me, and I doubt I'm the only one.

As for why the site plugin sucks so much, my guess is because there are far
fewer Maven *plugins* than Maven *projects*, and the site plugin is mainly
intended to document Maven plugins. So it gets hammered far less than, say,
maven-compiler-plugin does.

Regards,
Curtis


On Fri, May 31, 2013 at 2:17 PM, Stephen Colebourne <scolebou...@joda.org>wrote:

> It seems that the site plugin has lots of issues.
>
> I have a setup as follows:
> root/pom.xml (aggregator extends parent)
> root/projects/parent/pom.xml (parent)
> root/projects/child/pom.xml (real code)
>
> AFAIK, this is a pretty standard way to setup maven, apart from the
> extra "projects" folder.
>
> My parent has this config:
>   <distributionManagement>
>     <site>
>       <id>og-developer-site</id>
>       <url>http://foo.com/maven/site/${project.artifactId}/</url>
>     </site>
>   </distributionManagement>
>
> The aggregator has this config:
>   <distributionManagement>
>     <site>
>       <id>og-developer-site</id>
>       <url>http://foo.com/maven/site/</url>
>     </site>
>   </distributionManagement>
>
> The end result of runing "mvn site site:stage" in the aggregator/root
> folder is many errors.
>
> Firstly, it takes forever. It needlessly runs the
> validate/generate-sources phases of each subproject many, many times.
>
> Seondly, the output is calculating that the parent pom is the root of
> the output, not the aggregator pom. This messes up the generation.
>
> Thirdly, the aggregator generates these sections in the index.html:
>
> <h5>Modules</h5>
> <ul>
> <li class="none">
> <a href="og-parent/index.html" title="OG-Parent">OG-Parent</a>
> </li>
> <li class="none">
> <a href="og-analytics/og-analytics/index.html"
> title="OG-Analytics">OG-Analytics</a>
>
> While later on it creates:
>
> <tr class="b">
> <td><a href="../index.html">OG-Parent</a></td>
> <td>OpenGamma maven parent project</td></tr>
> <tr class="a">
> <td><a href="..\og-analytics/index.html">OG-Analytics</a></td>
> <td>OpenGamma platform analytics</td></tr>
>
> Two DIFFERENT url relativizations in the same file!
> The first is clearly wrong with a doubled up entry. But the second is no
> better.
>
> Finally, the site:stage manages to copy all the files one level higher
> than they should be:
>
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building OG-Parent 2.0.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-site-plugin:3.3:stage (default-cli) @ og-parent ---
> [INFO] Using this base directory for staging:
> C:\dev\og\maven\OG-Platform\target
> \staging
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Opened
> [INFO] Pushing C:\dev\og\maven\OG-Platform\projects\OG-Parent\target\site
> [INFO]    >>> to file://C:\dev\og\maven\OG-Platform\target\staging/./
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnecting
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnected
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building OG-Analytics 2.0.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-site-plugin:3.3:stage (default-cli) @ og-analytics ---
> [INFO] Using this base directory for staging:
> C:\dev\og\maven\OG-Platform\target
> \staging
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Opened
> [INFO] Pushing
> C:\dev\og\maven\OG-Platform\projects\OG-Analytics\target\site
> [INFO]    >>> to
> file://C:\dev\og\maven\OG-Platform\target\staging/../og-analyti
> cs/og-analytics
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnecting
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnected
> [INFO]
> [INFO]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building OG-Platform 2.0.0-SNAPSHOT
> [INFO]
> ------------------------------------------------------------------------
> [INFO]
> [INFO] --- maven-site-plugin:3.3:stage (default-cli) @ og-platform ---
> [INFO] Using this base directory for staging:
> C:\dev\og\maven\OG-Platform\target
> \staging
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Opened
> [INFO] Pushing C:\dev\og\maven\OG-Platform\target\site
> [INFO]    >>> to file://C:\dev\og\maven\OG-Platform\target\staging/..
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnecting
> file://C:\dev\og\maven\OG-Platform\target\staging/ - Session: Disconnected
>
> If you look, you'll see that the site:stage copied all the files
> ALONGSIDE the staging directory, rather than within it! (With the
> exception of the aggregator project, which this time the plugin
> decided to put in the right place).
>
> At the very least, the plugin should have a sanity check to prevent
> copying stuff outside the staging directory...
>
>
> I'd also note that the documentation across different plugins sites
> (javadoc/checkstyle/pmd/jxr/maven3upgradeNotes) is very unclear as to
> what the recommended way to declare config for reports is. Does
> everything go in build/plugins or pluginManagement or reporting? What
> overrides what? Do I have to duplicate everything? How does it
> actually work wrt multi-module builds?
>
> Or more bluntly - why is the guesswork the only solution to setting up
> maven? Is it to drive consultancy?
>
> The site plugin is one of maven's oldest. I expected clear
> documentation and it to "just work". Neither is true.
> Stephen
>
> PS. I didn't mention the NPE caused by simply configuring the javadoc
> plugin with links.
>       <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-javadoc-plugin</artifactId>
>         <version>2.9</version>
>         <configuration>
>           <links>
>             <link href="http://dist.fudgemsg.org/java/javadoc/0.3/"; />
>             <link href="http://threeten.github.io/threetenbp/apidocs/"; />
>             <link href="http://joda-beans.sourceforge.net/apidocs/"; />
>             <link href="http://joda-convert.sourceforge.net/apidocs/"; />
>             <link
> href="
> http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/";
> />
>           </links>
>         </configuration>
>       </plugin>
> With the links it gets NPE in MXSerializer writing javadoc options.
> Without the config it succeeds.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Reply via email to