updating title to be more intuitive of where the problem manifests, and upgrading priority.

different descriptions of the same problem.

The root problem here is that Maven builds a whole project at a time when executing a reactor build. This is only a problem because of the way in which project sorting occurs, where parent projects are built first, on the assumption that they need to be complete in order to be referenced by child project builds. This means that an assembly which is bound to the parent project, and which defines a moduleSet with a binaries section, CANNOT SUCCEED under the current reactor design. In this scenario, as the parent project is built it encounters the assembly step, and attempts to gather the binary artifacts for the applicable (child) modules. Since these children haven't been built yet, they don't have binary artifacts, and the assembly fails.

The only workaround for now is to keep the assembly step separate from the main build, and execute the following:

mvn clean package assembly:assembly

or similar. Using assembly:assembly has the advantage of executing as an aggregator, meaning it will use only the current root project for configuration, and will execute only once for the entire reactor, as opposed to normal mojos like assembly:single that will attempt to execute for each project in the reactor.

This is an ugly, ugly design issue that is currently without a clear solution in the development community.

The solution to this design issue (from Maven itself) is to create a child module solely to house the assembly. From this child, you can specify dependencies such that the child is built last in the multimodule build process.

Then, you can use moduleSets along with the new <useAllReactorProjects>true</useAllReactorProjects> flag inside the moduleSet section to gain access to all projects currently in the reactor, and process modules selected from that set.

John, do you consider this truly fixed or are you still looking for a cleaner solution? The assembly-only child module workaround is OK except that it requires some hack dependency manipulation to make it the last to build. This means that developers must remember to fix the assembly child module when they add or remove other modules--and we all know how that goes.