This is classic chicken and egg... having G depend on G plugins
that also depend on G for the plugin to be built.
This might have worked before in m1, but so far I have not been
able to get a plugin built and then used in the same build cycle
with m2.
this was allegedly one of the advantages of m2, it was nearly
impossible in m1.
Need to get some clarification from the Maven team, but from what I
have seen and tried... building plugins and modules that use those
plugins in the same cycle is not possible.
And, with m1 it is only barely possible with some rather massive hacks.
Both are a bad idea... and can be fixed by properly segmenting the
build and separating build concerns.
What parts of the build need these plugins?
packaging plugin >> configs
assembly plugin >> assembly
deployment plugin (any chance any one else will vote or should I
give up?) >> integration tests.
Is it just the config modules? If so then we may need to split
the build into two chunks, one that builds the modules and
plugins, and then another than builds the configs and assemblies.
Doesn't the listing of subprojects in top level pom.xml do this?
Negative. When m2 starts up it will scan all modules that are
configured and then scan its dependencies, and then continue to
process build dependencies (plugins, extensions, etc). If a module
depends on a plugin that does not exist in the repository it will
cause the build to fail... even if the module to build that plugin is
included on the build path.
There is another fly lurking ready to get into the ointment, it's
possible that we may eventually want to intersperse jar and car
(currently confusingly named modules and configs) builds in order
to completely align our dependency tracking with maven's dependency
tracking. Then we could use the poms instead of our own files.
Not sure what you mean by this could you explain a bit further?
--jason
