----- Original Message ----- > From: "Mikolaj Izdebski" <mizdebsk@xxxxxxxxxx> > To: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx> > Cc: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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 > -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
