This is a usability question but also dev related since the answer may
require/prompt changes to the dependency plugin.
I'm using assembly:attached to generate many different zip files that
package things I want to reuse. In this case, some data to be imported
into hsql for unit test purposes. This zip file occurs in a sub module
/data/modules. In /data/variants I have more assembly:attached things
that depend on the product of the rest of the builds. In otherwords, the
dependency tree effectively is: /data/variant[s] -> service jars ->
/data/module[s].
Since I'm using the dependency plugin to unpack/copy artifacts, these
zips are effectively dependencies but Maven doesn't know because they
aren't explicitely listed in the dependency section. We attempted to
list these zips as proper dependencies to affect the ordering, but in
doing so, Maven fails because it can't find a pom that matches the zip
(remember we have pom packaging with assembly:attached to deploy).
Putting the data child at the top of the module tree in the parent pom
works a little, but Maven still doesn't understand that some jars need
to be built before executing the data/modules assemblies. (we can
control a little by listing the jars as dependencies and won't run into
the missing pom problem like the assembly:attached zips but I'm looking
for a way to make the dependency-plugin more robust)
So, the question is: Is it possible to modify the dependency plugin in a
way to allow it to take part in the ordering phase that Maven does
before executing the builds? (ie to have it inject some dependencies to
the tree) Alternatively, is there a way to allow the dependency plugin
to detect that some artifacts are in the same reactor build and cause
them to be built before continuing? (fork perhaps? - not ideal because
presumably these modules would then be built 2x)
