upgrade common-collections / velocity?
Brent Putman
putmanb at georgetown.edu
Fri May 12 15:45:37 EDT 2017
On 5/12/17 2:52 PM, Rob Audenaerde wrote:
>
>
> I created a minimal project that has similar dependencies as the one
> where I have issues with. Below is the pom.xml.
>
> When I run:
>
> mvn dependency:list | grep collections
>
> This is the output:
>
> [INFO]
> commons-collections:commons-collections:jar:3.2.1:compile
>
> Also, when printing the dependency:tree I see that there is only one
> commons-collections: 3.2.1
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.
However, in an external project that's just pulling in opensaml-* deps
in the usual fashion, and which does not inherit from our parent POM,
no such dependency management is going on. So Maven is just resolving
that dependency transitively based solely on our explicit dependency on
velocity, and that's 3.2.1.
I don't know what, if anything, we can do about that. Or at least that
we'd be willing to do from a project management standpoint. Off-hand
I'm sure we could add an explicit commons-collections dependency to
the modules in OpenSAML (and the IdP) which use Velocity to force the
version explicitly, but that's probably messy and seems undesirable.
Maybe someone else on the team or the list who understands Maven better
than I do has another idea.
And if we do make some change, that's obviously not going to fix
anything for the already-released 3.3.0. So...
>
> I think I might fix this by include more depedencies? (and end up
> with one that has a higher commons-collections version), but I strive
> to include as few as possible...
... I think the best thing you can do right now is to just declare the
3.2.2 version in your own project's POM. I tested just adding a
dependency management section like below to my sandbox, and it works
for me:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>commons-collections</groupId>
<artifactId>commons-collections</artifactId>
<version>3.2.2</version>
</dependency>
</dependencies>
</dependencyManagement>
Which fixes things up:
# mvn dependency:tree -Dverbose -Dincludes=commons-collections
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ sandbox-v3 ---
[INFO] brent:sandbox-v3:jar:0.0.1-SNAPSHOT
[INFO] \- org.opensaml:opensaml-saml-impl:jar:3.4.0-SNAPSHOT:compile
[INFO] \- org.apache.velocity:velocity:jar:1.7:compile
[INFO] \-
commons-collections:commons-collections:jar:3.2.2:compile (version
managed from 3.2.1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170512/5e2fa8dd/attachment-0001.html>
More information about the dev
mailing list