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>
  Mojos (org.apache.maven.plugin.assembly.mojo) |
| Uses: |
 AssemblyArchiver |
| Provides: |
| implementation of AssemblyConfigurationSource, for use in assembly components |
| Notes: |
| AssemblyConfigurationSource transports build state given by mojo parameters to deeper assembly components |
| AssemblyArchiver abstracts the business of creating the assembly artifact from the mojos |
| AssemblyArchiver (org.apache.maven.plugin.assembly.archive) |
| Uses: |
| ArchiverManager |
| the set of ArchiveAssemblyPhase implementations |
| AssemblyDescriptorReader and AssemblyInterpolator |
| Provides: |
| logic to discover and read assembly descriptors |
| AssemblyDescriptorReader and AssemblyInterpolator help with this task |
| logic to discover and add filters that merge container descriptor files |
| these are implementations of ContainerDescriptorHandler |
| Notes: |
| Archiver instances are retrieved from the ArchiverManager |
| Archiver instances are wrapped with AssemblyProxyArchiver, which adds global prefixing, dry-run, and duplicate detection features |
| ArchiveAssemblyPhases execute the actual interaction with the (proxied) Archiver instance to produce the assembly |
| AssemblyProxyArchiver is the only one initialized as a POJO with the real Archiver component instance passed into the constructor; all other classes used by the AssemblyArchiver are components injected by Plexus |
| ArchiveAssemblyPhase instances are injected via a Map which is keyed by their respective role-hints; I don't believe the ordering of keys in this map is deterministic. |
| ContainerDescriptorHandler instances are components that are injected via a Map which is keyed by their respective role-hints. Custom implementations can be added via the plugin-level dependency configuration in the pom.xml |
| ArchiverAssemblyPhase (org.apache.maven.plugin.assembly.archive.phase) |
| Default Implementations: |
| ModuleSetAssemblyPhase |
| DependencySetAssemblyPhase |
| FileSetAssemblyPhase |
| FileItemAssemblyPhase |
| RepositoryAssemblyPhase |
| Uses: |
| ArchiverTask implementations, as POJOs |
| FileFormatter (FileItemAssemblyPhase) |
| RepositoryAssembler (from maven-repository-builder; used by RepositoryAssemblyPhase) |
| Notes: |
| Initialized as Plexus components |
| generally, each implementation handles one top-level section of the assembly descriptor |
| phases share common logic in terms of how they interact with the Archiver instance; this is captured in different ArchiverTask implementations |
| ArchiverTask (org.apache.maven.plugin.assembly.archive.task) |
| Default Implementations: |
| AddArtifactTask |
| AddDependencySetsTask |
| AddDirectoryTask |
| AddFileSetsTask |
| Uses: |
| DependencyResolver (AddDependencySetsTask) |
| FileSetFormatter (AddFileSetsTask) |
| Notes: |
| Used as POJOs that are initialized then executed by different ArchiverAssemblyPhase instances. |
| ContainerDescriptorHandler (org.apache.maven.plugin.assembly.filter) |
| Notes: |
| Added to the AssemblyProxyArchiver as a filter and finalizer |
| Ability to cherry-pick files before they're added to the assembly archive, and process them (processing usually means aggregation/merging, but could be anything) |
| Ability to add a set of "virtual" files to the assembly archive just before it is closed. |
| ComponentsXmlArchiveFileFilter (for plexus components.xml files) is always present during the assembly process. |
| DependencyResolver (org.apache.maven.plugin.assembly.artifact) |
| Uses: |
| ArtifactFactory from maven-artifact |
| ArtifactRepository from maven-artifact |
| MavenProjectBuilder from maven-project |
| ArtifactResolver from maven-artifact |
| MavenMetadataSource/ArtifactMetadataSource from maven-project/maven-artifact |
| Notes: |
| Selects the best implementation of ArtifactResolver it can find, based on a String-array of preferential role-hints. If none of the preferred resolvers can be found, it defaults to a lookup without any role-hint. This is necessary for compatibility with maven 2.0.x. |
| This component can take a List of remote repositories from the current build, append to this the List of remote repositories from the project passed in (avoiding duplicate entries, based on repository id), and use that as a basis for resolving dependency artifacts |
| AssemblyConfigurationSource.isUseTransitiveDependencies() is used in calling components to control whether this component (the resolver) does a full transitive resolution of the project's dependencies, or just resolves the direct dependency artifacts |
| FileFormatter (org.apache.maven.plugin.assembly.format) |
| Uses: |
| AssemblyFileUtils for line-ending normalization and temp-dir/temp-file management |
| Provides: |
| Interpolation of a given file's contents, based on project values and an optional Properties file or set of filter files (supplied by AssemblyConfigurationSource) |
| Normalization of line endings, using values: keep (don't change), dos (\r\n), crlf (\r\n), unix (\n), lf (\n) |
| Notes: |
| If line ending is not 'keep', the final line in the file will always end with a newline string, regardless of whether this is the case in the original file. See MASSEMBLY-96. |