movw $0x1f01,0xb8000; hlt;

If the Javadoc plugin triggers a java.lang.ClassCastException when running the maven site plugin, you’re likely to hit http://jira.codehaus.org/browse/MSITE-432.

In a nutshell, the Javadoc command line isn’t populated properly when run as part of the site reports generation. test-jar dependencies are to blame. If you depend on artifact A:jar and A:test-jar, the former is not added to the classpath of Javadoc.

A workaround is to declare test-jar first (to make sources Javadocs work), before the jar dependency, and skip generation of tests Javadocs (since the tests Javadocs will now fail), i.e. transform

    <dependencies>
        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
        </dependency>
        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <type>test-jar</type>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <reporting>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
            </plugin>
        </plugins>
    </reporting>

into

    <dependencies>
        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
            <type>test-jar</type>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>...</groupId>
            <artifactId>...</artifactId>
        </dependency>
    </dependencies>

    <reporting>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-javadoc-plugin</artifactId>
                <reportSets>
                    <reportSet>
                        <id>html</id>
                        <reports>
                            <report>javadoc</report>
                            <!-- No test-javadoc See http://jira.codehaus.org/browse/MSITE-432 -->
                        </reports>
                    </reportSet>
                </reportSets>
            </plugin>
        </plugins>
    </reporting>

See the fix implemented for the Dwarf serialization library here.

If you add the Maven Shade plugin in the top pom.xml of a multimodule project, mvn deploy will fail in the following way:

------------------------------------------------------------------------
[ERROR] BUILD ERROR
------------------------------------------------------------------------
[INFO] Error deploying artifact: Failed to transfer file:

http://mavenrepo/nexus/content/repositories/libs-snapshots-local/com/ning/metrics.serialization/1.0.2-SNAPSHOT/metrics.serialization-1.0.2-20101103.193531-5-jar-with-dependencies.pom.

Return code is: 400

Nexus is actually complaining that you are trying to upload a 0-byte pom.xml (you’ll have to resort to Wireshark to debug the issue, as the plugin won’t be more verbose about the error).

The problem comes from trying to assemble the final artifact from the parent pom. As mentioned in http://jira.codehaus.org/browse/MASSEMBLY-420 (covers the Assembly plugin, but it’s the same behavior for Shade), this introduces a circular dependency in the build:

In a multimodule hierarchy, when a child module declares the parent POM in its <parent/> section, Maven interprets this to mean that the parent project’s build must be completed before the child build can start. This ensures that the parent project is in its final form by the time the child needs access to its POM information.

In cases where the Assembly Plugin is included as part of that parent project’s build process, it will execute along with everything else as part of the parent build – before the child build can start. If the assembly descriptor used in that parent build references module binaries, it effectively expects the child build to be completed before the assembly is processed. This leads to a recursive dependency situation, where the child build depends on the parent build to complete before it can start, while the parent build depends on the presence of child-module artifacts to complete successfully.

The solution is to create a dummy maven submodule which depends on all submodules of the project (so it is built last) and which executes the Shade plugin (i.e. move the Shade plugin configuration to a submodule pom.xml, instead of having it in the parent pom).

Checkout the Dwarf serialization library for a practical example: parent pom.xml, dummy module.

I have just released hfind 1.0.1.

Among its new features:

• -print0 to separate pathnames with an ASCII NUL character instead of a newline. This is to be used in conjunction with xargs -0.
• -delete, which deletes matching files and directories.
• -v,–verbose prints the full HDFS URI (e.g. hdfs://namenode.company.com:9000/user/pierre instead of /user/pierre). It also prints deleted files when used with -delete.

See the NEWS file for the full changelog.

The 1.0.1 build is on Github. Please report any issue on the Github bug tracker.