----- Original Message -----
From: "Mikolaj Izdebski" <mizdebsk(a)redhat.com>
To: "Aleksandar Kurtakov" <akurtako(a)redhat.com>
Cc: "java-devel" <java-devel(a)lists.fedoraproject.org>
Sent: Friday, February 22, 2013 11:43:34 AM
Subject: Re: Installing effective Maven POM files
> 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.
One more question - if I configure my parent pom to never be embedded I would still have
to care for adding BRs myself, right? So no additional problems would arise from being
able to use mvn-rpmbuild/local that rely on normal poms.
Alexander Kurtakov
Red Hat Eclipse team
--
Mikolaj Izdebski