Reputation: 219
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
My Questions are:
a) Does this approach make sense? What if I need to upgrade Project B dependencies, wouldn't that warrant a change for Project A and Project C?
b) Is there a way to mandate that Maven - Enforcer plugin is run every time a build is run for a project?
c) What could be the other advantages of having common dependencies maintained in Super POM?
Thanks much in advance.
Upvotes: 1
Views: 133
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
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