> Now to the problems with embedding poms aka effective poms - There > are parent poms like > (http://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse-parent/pom.xml > ) which contain way more information than one would think - like > supported architectures, set of bundles in a bundle pool to be used > when running some tasks and etc. Now consider that this is the > parent pom of few maven plugins like maven-cbi-plugin, > eclipse-jarsigner-plugin and others. So the parent pom gets embedded > in the plugins pom and I want to add one more arch (e.g. arm64). In > this case I would have to rebuild all the plugins (even this is > unacceptable) so they get the arm64 arch embedded in them, while > this might work if everything is noarch and I do it on the primary > archs, it becomes impossible to do it if there is arch specific > parts(and yes we do have them - calling eclipse and etc.) cause I > would need to run the cbi to build the jarsigner but the cbi has > embedded config that arm64 is not supported hence fail the build. So > in this case we end up in no way to do something as simple as adding > one more arch which in the old case was just patching the parent and > everything works. In this case the solution would be very simple - install raw POM instead of effective POM just in this case. > Another problem is the benefit from effective poms - it's > questionable if you don't rely on maven to handle your dependencies > - aka for OSGi case - a lot of additional work for no direct > benefit. Again, you could disable generation of effective POM in cases where it's not suitable for you (just like you can disable auto-requires or filter them with a regular expression). The idea is that you can have common build settings which work for the majority of packages and customize them as needed. -- Mikolaj Izdebski -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
