> 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 -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
