----- Original Message ----- > From: "Stanislav Ochotnicky" <sochotnicky@xxxxxxxxxx> > To: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, February 20, 2013 4:58:23 PM > Subject: Re: Installing effective Maven POM files > > 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? You do understand that I don't have that deep knowledge in other stacks to answer that question. It's definetely a problem in Eclipse stack and something you don't care about in Maven stack but none of us knows about others. > > 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? This goes against having guidelines at all- if we have maven guidelines we need to move in direction making it suitable for everyone (incl. Eclipse). I would like to see Eclipse plugins using the same technique as others using Maven so make them rely on the same macros (even if we would have to develop some maven plugins/extensions for that). We got really close to that state with mvn-rpmbuild so diverging now would be a step back. > > 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. No, what would be acceptable though is having a marker in the parent pom package that this parent should never be embedded. Still one question will stay open - diverging from upstream more than we did before with the patched maven. I know I haven't answered Mikolaj's question about upstream usability but many of us do use mvn-local to do upstream work and benefit from the Fedora system integration which would be irrecoverably lost as having different poms from maven central in our ~/.m2 would be a no go. Alexander Kurtakov Red Hat Eclipse team > > > -- > Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx> > Software Engineer - Base Operating Systems Brno > > PGP: 7B087241 > Red Hat Inc. http://cz.redhat.com > > -- > 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
