Now to the problems with embedding poms aka effective poms - There
are parent poms like
(
http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/...
) which contain way more information than one would think - like
supported architectures, set of bundles in a bundle pool to be used
when running some tasks and etc. Now consider that this is the
parent pom of few maven plugins like maven-cbi-plugin,
eclipse-jarsigner-plugin and others. So the parent pom gets embedded
in the plugins pom and I want to add one more arch (e.g. arm64). In
this case I would have to rebuild all the plugins (even this is
unacceptable) so they get the arm64 arch embedded in them, while
this might work if everything is noarch and I do it on the primary
archs, it becomes impossible to do it if there is arch specific
parts(and yes we do have them - calling eclipse and etc.) cause I
would need to run the cbi to build the jarsigner but the cbi has
embedded config that arm64 is not supported hence fail the build. So
in this case we end up in no way to do something as simple as adding
one more arch which in the old case was just patching the parent and
everything works.
In this case the solution would be very simple - install raw POM instead
of effective POM just in this case.
Another problem is the benefit from effective poms - it's
questionable if you don't rely on maven to handle your dependencies
- aka for OSGi case - a lot of additional work for no direct
benefit.
Again, you could disable generation of effective POM in cases where it's
not suitable for you (just like you can disable auto-requires or filter
them with a regular expression).
The idea is that you can have common build settings which work for the
majority of packages and customize them as needed.
--
Mikolaj Izdebski