upgrade common-collections / velocity?

[Brent Putman]

On 5/13/17 12:47 PM, Cantor, Scott wrote:
> On 5/12/17, 3:45 PM, "dev on behalf of Brent Putman" <dev-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
>
>> 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.
> 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.

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.

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.

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).


> I think that essentially means owning the testing and integration job of all the dependencies. 

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).


> 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.

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170513/59362bf3/attachment.html>