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(a)redhat.com>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc.
http://cz.redhat.com