upgrade common-collections / velocity?

Etienne Dysli-Metref etienne.dysli-metref at switch.ch
Mon May 15 08:30:43 EDT 2017


On 13/05/17 19:15, Brent Putman wrote:
> 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.

Spring solves this by providing a "bill of materials" POM [1] meant to
be included in <dependencyManagement>. It ensures that all Spring
Framework artifacts are at the same version. Spring Boot goes even
further and manages its transitive dependencies in a BOM to provide a
consistent, tested set of libraries.

I already suggested using the Spring BOM in your java-parent project to
simplify its POM [3]. Come to think of it, also providing a BOM for the
IdP would be really convenient for extension developers.

  Etienne

[1]
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/overview.html#overview-maven-bom
[2]
https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#using-boot-maven-without-a-parent
[3] https://issues.shibboleth.net/jira/browse/JPAR-70

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://shibboleth.net/pipermail/dev/attachments/20170515/f0bb9baf/attachment.sig>


More information about the dev mailing list