Yes. The assemblies created by the Assembly Plugin is attached to your project so it gets deployed too.

Yes. You can refer to it using the id of the assembly as the dependency classifier.

The Javadoc Plugin can generate the javadoc files of your projects. Also, the Javadoc Plugin can package them!

Please see the Javadoc Plugin Documentation.

Use the single or directory-single goal.

Since the assembly, attached, directory, and directory-inline goals are all aggregators, they will execute at most once per execution of Maven. See Atypical+Plugin+Use+Cases (wiki) for more information on the problems associated with aggregator mojos.

If your assembly includes module binaries, those binaries won't be available to the assembly plugin except in special cases. This is normally seen when the Assembly Plugin is bound to a phase of the standard build lifecycle. It happens because of the way Maven sorts and executes the build process for a multimodule project layout.

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. Since these artifacts are missing, the Assembly Plugin will complain about missing artifacts, and the build will fail.

In many cases, you can avoid this problem by adding a new child module whose sole purpose is to produce your assembly. In the POM for this new project, add dependency definitions for any of the module binaries you had previously referenced. Then, move your assembly descriptor into this new child module, and change all module-binary references to dependencySet references. Obviously, any fileSet or file references you may have in this descriptor may need to be adjusted or have the files they reference moved into the new child module alongside the descriptor itself.

In cases where you absolutely must use module-binaries references, you should avoid binding your assembly into the main build lifecycle. Modify your POM so that the Assembly Plugin configuration is defined in the main the plugin declaration, then remove the executions block from that plugin declaration (which supplies the phase and goal specifications that create the lifecycle binding). Finally, to process this assembly, you'll need to execute something like this:

mvn package assembly:assembly

to force Maven to build the entire multimodule structure to the 'package' phase before attempting to process the assembly. This ensures the module artifacts are present to satisfy your module-binaries definitions.

The best way to handle a mixed bag of dependencies with and without classifiers is to use the ${dashClassifier?} expression, added in version 2.2-beta-2 of the assembly plugin especially for this purpose. This expression will determine whether each artifact has a classifier, and if it does, it will substitute the artifact's classifier - prepended by a dash - in place of the expression.

For example, suppose you want to include two artifacts, commons-logging-1.0.4.jar, and yourserver-1.0-client.jar (where 'client' is the classifier of the second artifact). To do this, simply add the following to your dependencySet:

<outputFileNameMapping>${artifact.artifactId}-${artifact.version}${dashClassifier?}.${artifact.extension}</outputFileNameMapping>