Quoting Aleksandar Kurtakov (2013-02-20 16:10:40) > > > > 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. Fair enough. For what it's worth I believe parent poms are rarely receiving such high churn of breaking changes as you are seeing in Eclipse right now. > > > > 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. Right, I do believe extending XMvn for use with Eclipse is not that hard to do. Which is something mvn-rpmbuild could never achieve since it was one big hack. And I *do* believe that XMvn would be the best way to handle this in the future. My question was about current state of affairs. I.e. while you keep using mvn-rpmbuild the issue is not affecting you and in the meantime we can work on a solution(s) to this in more specialized way. I.e. develop additional XMvn plugin for use in eclipse packaging or whatnot. > > 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. Hmm, ok that sounds like workable solution at first glance (to me at least). > 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. It's just hard for me to justify honoring exact upstream replicas of pom.xml files when we actually ignore most of the versions in there. I believe installing raw poms alongside effective would not help your case at all. But we *could* have both and have xmvn be able to switch between them just for sake of testing with upstream versions. That seems like an amazing way to complicate things though... -- 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
