----- 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.
Sure, but the pom installed will be patched.
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.
Try selling this to some upstreams first.Including a config for a tool would require full
IP review of xmvn before config for it being accepted.
> 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.
True, I completely understand that. But please do understand that people need pristine
environment. It's not about packaging only, it's about development usage. There
are cases to use mvn-rpmbuild/mnv-local outside of packaging. This cost is not that high
for the ability to fix when problems arise. I can understand you if you want mvn-rpmbuild
don't work that way by default but being activateable via flag - it works perfectly
well for me.
Alexander Kurtakov
Red Hat Eclipse team
--
Mikolaj Izdebski