----- Original Message ----- > From: "Mikolaj Izdebski" <mizdebsk@xxxxxxxxxx> > To: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, February 20, 2013 4:35:23 PM > Subject: Re: Installing effective Maven POM files > > > 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. The problem is that usually you find out the one more place where you needed to do that once it's too late. Alexander Kurtakov Red Hat Eclipse team > > -- > Mikolaj Izdebski > -- > java-devel mailing list > java-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
