<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 5/13/17 12:47 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:83F9903E-0BE9-4174-882A-03B3A1D41A8D@osu.edu">
<pre wrap="">On 5/12/17, 3:45 PM, "dev on behalf of Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:dev-bounces@shibboleth.netonbehalfofputmanb@georgetown.edu"><dev-bounces@shibboleth.net on behalf of putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Yes, you are correct. I see the same thing in a sandbox project. I belatedly realize why this is. In all of our own code, we are
getting the 3.2.2 version by explicitly managing this dependency in our parent POM. All our projects' POMs derive from this
parent POM, and so that's what is effective.
</pre>
</blockquote>
<pre wrap="">
I had thought, I guess mistakenly, that it was a given that any dependency on OpenSAML required using our parent POM. And that's what I would do, personally.</pre>
</blockquote>
<br>
I personally did not and would not consider that to be a
requirement. Some other project may have its own internal parent
POM like us (big projects, companies, etc often do), and because
Maven is single inheritance, you see the fundamental problem with
that proposition.<br>
<br>
However... After I sent the above, I realized that in fact I am not
really sure why Maven is behaving this way. So I retract my
statement above. Basis: OpenSAML effectively declares that
commons-collections dep should be 3.2.2 in its effective POM (or so
we think). Maven has access to that full effective POM (including
its parent(s)) when processing some other project's dependency on
OpenSAML. So one would think - as we both originally did - that
3.2.2 is what should be effective. So either Maven's dependency
resolution strategy works differently than is intuitive, or it has a
bug.<br>
<br>
Re the former, I don't know, but maybe it has to do with our use of
dependencyManagement. Maybe it just doesn't work in all cases the
way we think it does, for example when a downstream project is
dependent on you. Well, maybe that's even self-evident at this point
(assuming Maven doesn't have a bug here).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:83F9903E-0BE9-4174-882A-03B3A1D41A8D@osu.edu">
<pre wrap="">I think that essentially means owning the testing and integration job of all the dependencies. </pre>
</blockquote>
<br>
It does unless/until we figure out wtf is going on. At this point
I'm really not sure. I mean, we in fact may be in the same boat wrt
our own dependencies. Have we ever actually looked in detail at all
of our dependencies' dependencies to see that we're actually getting
what we/they think we should? I personally haven't (b/c we assume
it works rationally).<br>
<br>
<br>
<blockquote type="cite"
cite="mid:83F9903E-0BE9-4174-882A-03B3A1D41A8D@osu.edu">
<pre wrap="">If you wanted to get a system operating as tested and delivered in the only context in which we test and deliver OpenSAML, you'd use our parent POM.
</pre>
</blockquote>
<br>
But you see the inherent issue with that. He could do that, but
only for *us*. That's not generally going to be a useful universal
strategy. For example, what if both Spring and Santuario had the
same position, requiring us to inherit from a hypothetical parent
POM that each had? We couldn't (easily) do it, due to the single
inheritance.<br>
<br>
<br>
<br>
</body>
</html>