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.
As part of the deprecation of all goals except for the single goal, the goals of the Assembly Plugin and their configuration/executions are no longer inherited by default.
If you need the configuration/executions to be inherited you need to explicitly say so by adding a line to the plugin declaration in the parent POM:
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<inherited>true</inherited>
...
The use of <descriptors/> was always incorrect, and counter to the design of this configuration parameter. Unfortunately, some code was introduced in version 2.2-beta-2 that allowed this parameter to reference descriptors on the classpath, instead of being forced to use <descriptorRefs/> as is the intention of the design. In version 2.2, this bug was fixed.
It is important to note that the correct form, <descriptorRefs/< has always worked, and continues to work. The documentation has now been fixed to reflect the correct configuration.
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 and higher.
The assembly id is used for reporting and calculating descriptor/component merges. They're also required to avoid collisions with the main output of the project's build process. It's critical that this id be in place, to overriding the project's main artifact inadvertently, and to help error-reporting make sense to the user. Leaving off the assembly id has always been an error, but unfortunately previous releases contained a bug in the model that allowed empty or missing assembly id's. This bug has been fixed in version 2.2.
However, in certain cases it makes sense to use the assembly output as the main project artifact. So, what's the correct approach in these situations? This use case is meant to require deliberate configuration, so your intention to depart from the normal behavior will be clear. To configure the use of the assembly output as the main project artifact, follow these steps:
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>
You can use :
GNU tar has restrictions on max value of UID/GUID in tar files. Consider using the more well defined POSIX tar format, which should support larger values. Use tarLongFileMode=posix in the assembly:single goal.