OK, the simplest case that would not work for us if we can't make
use
of the normal poms.
1. eclipse-cbi-plugin calls eclipse to run various tasks implemented
in eclipse
2. the bundle set needed to run eclipse is defined in eclipse-parent
3. eclipse platform changes and adds additional bundle
4. eclipse-parent is updated to add new dependency
5. eclipse-cbi-plugin can't be rebuild as it requires to run eclipse
which needs additional bundle which is in the parent but not in
eclipse-cbi-plugin package. I know that cyclic dependencies are bad
but these is the norm in Java land and this is not the only cycle.
6. if in this case we can call mvn-rpmbuild which relies on normal
poms - no problems as parent is correct.
I already provided a solution for this case - read my previous emails.
Do you have any *other* problems with effective POMs?
Note that patching eclipse-parent pom to add xmvn configuration is
not ideal solution as it would mean that xmvn would need to be
resolvable in case one runs pure mvn or during development one would
need to switch between upstream/fedora eclipse-parent pom (e.g. one
runs mvn-local and gets a failure, run pure mvn to test whether it's
smth in fedora that caused the problem and things fail because xmvn
is not resolved).
That is not true. XMvn configuration is placed in pluginMagement.
Plugins described in pluginMagement don't need to be resolvable.
Exactly the same solution is used in other projects, even on eclipse
side (Eclipse M2E stores its configuration exactly in the same way
(in pluginManagement in POM).
As much as this might sound imaginery to some
people this is common case if you both work upstream and keep care
of the integration in Fedora. Any such modification introduces
churns which are very easy to overlook and either push to upstream
xmvn specifics or push to Fedora without xmvn configs so break other
things later.
Maintaining your own configuration is fairly simple. With POM macros
you don't even need to patch your POM files - configuration can be
specified directly in the spec file and injected during the build.
As long as you don't want to modify the semantics the maintenance
cost of this solution is close to zero.
Pushing XMvn configuration to upstream is an option - it won't affect
upstream build at all. Many upstreams include M2E configuration in
their POMs, which is analogous to XMvn configuration.
Keep mvn-local/mvn-rpmbuild to use normal poms and I would have no
objections.
That's not an option. This would cause severe problems with
dependencies. Let me give an example.
apache-commons-io installs effective POM and normal POM. It doesn't
Require apache-commons-parent. If you use mvn-rpmbuild to build the
package you either need to either BuildRequire apache-commons-parent
in your package or the build will fail because of missing parent POM.
--
Mikolaj Izdebski