This approach is kind of error prone. The assembly I want to make basically
packages whole directory. So I want it to be invoked after _all_ submodules
are built, with an assumption that set of the submodules could change over
time and I don't want to fix assembling every time this happens.



On Fri, Nov 16, 2012 at 1:25 PM, Ansgar Konermann <
ansgar.konerm...@googlemail.com> wrote:

> Read this first (the useAllReactorProjects flag notes, especially):
>
>
> https://maven.apache.org/plugins/maven-assembly-plugin/examples/multimodule/module-binary-inclusion-simple.html
>
>
> https://maven.apache.org/plugins/maven-assembly-plugin/faq.html#module-binaries
>
> Create a new child module to produce the assembly, have this module depend
> on the child modules you want to include the binaries from AND use an
> assembly descriptor having useAllReactorPlugins set to true.
>
> Am 16.11.2012 22:06 schrieb "Ivan Dubrov" <dubrov.i...@gmail.com>:
> >
> > Hi,
> >
> > During non-parallel build aggregate POMs are built last provided there is
> > no parent-child relationships between it and its submodules (correct me
> if
> > I am wrong).
> >
> > Is that preserved during parallel builds? Can I assume that root POM is
> > built after all its submodules are built? According to the build logs, it
> > seems like the answer is "no", but maybe I am missing something.
> >
> > If answer is "no", how can I ensure that aggregate POM is built last? For
> > example, I want to run assembly plugin after all submodules are built (in
> > parallel build)? Of course, I can run separate "mvn -N assembly:assembly"
> > command to assemble built stuff, but is there a way to do that during
> > regular build?
> > I don't want to specify dependencies explicitly since it could be
> > error-prone (submodules dependencies could change, for example).
> >
> > Can we have this convention back? Make
> > org.apache.maven.project.ProjectsSorter to add "weak" dependencies from
> > aggregate module to all its submodules?
> >
> > --
> > WBR,
> > Ivan Dubrov
>



-- 
WBR,
Ivan Dubrov

Reply via email to