Quoting Mikolaj Izdebski (2013-02-20 15:35:23) > > 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. Question for Alex: I assume you care about Eclipse stack not using effective poms correct? It's unlikely that apache-commons-parent will cause issues since they don't change your settings (i.e. you are not inheriting from them) and it's pretty stable. Is there any example outside of Eclipse parent chain which would cause you issues if they used effective poms? Eclipse packages are not using mvn_install macro so they are not affected at all (i.e. you are still installing raw poms) and relying on OSGI auto requires instead of Maven auto requires. Or am I missing something? Still I guess there can come a situation where we want to use mvn_install but still handle parent pom requires manually. And so... Question for Mikolaj: How much time would it take to implement that? I assume it's not that hard to have optional switch someplace which would make mvn_install install raw pom. Question for Alex: Would optional installation of raw pom instead of effective with specific warning that maintainer is responsible for updating proper requires be acceptable? While you ponder the answer, realize there are ~500 packages that use Maven, most of them are not Eclipse related and thus would likely benefit from proper automatic requires even if Eclipse doesn't. -- Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> Software Engineer - Base Operating Systems Brno PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: signature
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
