savv'y
savv'y

Reputation: 219

Shared Dependencies across unrelated projects

We are considering a custom super POM for maintaining common Spring, Hibernate, Logging dependencies present in multiple unrelated projects.

These projects have different release cycles catering to different business functions.

Reasons why we want to do this are

  1. Ensure a common framework across the entire organization for better future maintenance
  2. Ensure upgrades to OS versions do not have cascading effects on the multiple projects requiring to upgrade each and every project.

My Questions are:

Thanks much in advance.

Upvotes: 1

Views: 133

Answers (2)

greglevilain
greglevilain

Reputation: 101

It makes sense to use a corporate parent POM to ensure a consistent set of dependencies. And this is very usefull as soon as you deal with Spring/Hibernate projects. But this approach works only if someone is in charge of maintaining the super POM and creating new versions of it when projects need it. And also to support teams on the migration process as soon as a new version of the super POM is available (better future maintenance). This is possible but not trivial.

If you have a lot of projects, you will probably need more than one super POM. Otherwise, some of your projects will depend on un-necessary dependencies. For example, you could have some projects with a UI layer and others without UI layer.

The approach I recommend for projects based on Spring/Hibernate is to use the Spring Boot dependencies. The Spring Boot team makes the work of ensuring a consistent set of dependencies for you, in a very flexible way.

With this approach, you don't need a dedicated person for maintaining your enterprise POM and you benefit the Spring's team skills. Your teams are free to upgrade to a new set of Spring Boot dependencies when maintenance is necessary.

Check these 2 links for details on how to use Spring Boot dependencies:

Upvotes: 1

Markus W Mahlberg
Markus W Mahlberg

Reputation: 20703

Generally speaking, it makes sense. But it depends on your actual use case. I would not do this for log4j for example, but security related dependencies might make sense as you don't want to release something insecure, do you?

You can tie the enforcer plugin to some late phase, of course.

I do not see many advantages in a super POM for unrelated projects. The only reason I would use it to ensure that security related stuff like jasypt or spring-security stays state of the art.

You could use the BOM pattern described in the maven docs.

Upvotes: 1

Related Questions