You should use the single mojo. All mojos except for single have been deprecated.
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 goal.
NOTE: All other mojos have been deprecated, either because they can cause strange and unpredictable behavior in a variety of situations, or because they are redundant given the availability of the dir assembly format and the maven-dependency-plugin.
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 in the parent POM of a multimodule build. It is a result 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. This will ensure the new assembly child is built last. Then, move your assembly descriptor into this new child module. At this point, you have the option of either changing all moduleSet/binaries references to dependencySet references, or you can keep the moduleSets and instead set the useAllReactorProjects flag to true for each moduleSet.
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 create an assembly-child POM mentioned above, then insert <useAllReactorProjects>true<useAllReactorProjects> to each of your moduleSet sections. Then, bind the assembly in your assembly-child POM (normally to the package phase) using the single goal. When you execute the build from the top-level POM, Maven should generated your assembly in the new child project.
NOTE: The useAllReactorProjects flag is only available in version 2.2-beta-6 and higher.
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>