It is not just a question of what goals are associated with the phases of the POM project life cycle. If this were so, then binding the target of the “package” would solve the problem.
When creating a multi-module project, Maven reads the POM of all modules to determine the dependencies between the modules so that it can create modules depending on them before the dependent modules. It can achieve this even when the “package” target is run (so that module-specific modules are not yet in the local repository).
Therefore, the code that creates the classpath for the assembly should handle several cases, in particular:
- dependencies due to an additional project, where he looks for POM in the local repository, processes its dependencies and adds the POM jar to the class path
- project-dependent pom, where it searches for POM in the local repository and processes its dependencies
- dependency between jar projects, where it searches for POM in the project tree, processes its dependencies and adds this module target / classes folder to the class path
- dependency between pom projects, where for some reason it does not look for POM in the project tree and therefore does not handle dependencies.
Note the asymmetry in the last two cases compared to the first two.
I see two solutions to your problem. One of them is to report an error, or rather, a request for a change in behavior (since it is clearly intentional), perhaps only for cases between projects depending on multi-module projects. Or really offer a patch. But since the behavior is intentional, you may encounter failure. At best, you have a long wait. (I voted for your bug report, though - I was amazed at the same behavior in a different context.)
Another solution is to simply start the installation in your project. I really don’t understand why you don’t want the POM project in your repository: if necessary, you can use the snapshot repository where it doesn’t matter if things change often to avoid pollution of your main repository.