Thank you Nils,
I apologize for my ignorance, as I am still fairly new to Maven. I
understand the basics well enough but it is very obvious to me that
there is a lot of specialized knowledge that is assumed and not well
explained in most of the tutorials/guides I googled.
My library is a primary component of an in-house framework like yours.
I am at the start of modernizing and strengthening security of the
framework and all of my older projects from plain Java 8+Spring to
Maven, Java 17, Spring Boot, strong/secure authentication mechanisms,
and relying on a vault. I am not *yet* migrating to Docker and
Kubernetes (since my upper management did not approve it and also
because it would be a steep learning curve on top of the other new
things) but that seems to be a natural next step.
I read that BOM article and many others that I googled. If I understood
correctly, it seems that the ideal POM structure is:
* To have a master BOM POM that specifies key library versions and
pre-supplied BOMs (like spring-framework-bom) in the
dependencyManagement section.
* Maybe have a couple "parent" POMs for the different types of
projects (like REST service, webapp) that inherit from the master
BOM POM.
* And finally inheriting from one of those parent POMs in the
individual project POMs.
*First question*: Is that correct?
*Second question*: Where do I place the master BOM POM and the Parent
POMs so that they end up in the local Maven repository and visible to
project builds? I suspect that the answer might be to create a dummy
Eclipse project with multiple POMs and no code, then use something like
the following but I am not sure:
|||<||parent||>|
|||<||groupId||>com.mydomain</||groupId||>|
|||<||artifactId||>poms</||artifactId||>|
|||<||version||>0.0.1-SNAPSHOT</||version||>|
|||<||relativePath||>bom-pom.xml</||relativePath||>|
|||</||parent||>|
|||<||parent||>|
|||<||groupId||>com.mydomain</||groupId||>|
|||<||artifactId||>poms</||artifactId||>|
|||<||version||>0.0.1-SNAPSHOT</||version||>|
|||<||relativePath||>parent-rest-pom.xml</||relativePath||>|
|||</||parent||>|
On 1/26/2022 5:26 AM, Nils Breunese wrote:
Bruno Melloni<x.lo...@melloni.com> wrote:
If I understood the explanation, it seems that the spring boot starter (parent)
defaults to slf4j and that the code above removes that support while replacing
it with log4j2.
I don’t know what your goals are for this library, but I do wonder if it’s a
good idea to let a library depend on Spring Boot starters. I would expect that
more gets pulled in than you actually want or need, as you’ve found. Spring
Boot starters are just artifacts that depend on one ore more other artifacts
and are generally meant to be used by applications. Libraries typically depend
on one or more those ‘lower level’ artifacts directly to explicitly define what
they depend on and not pull in too much.
I maintain an in-house framework based on Spring Boot myself and I’d recommend
importing the spring-boot-dependencies BOM of the Spring Boot version you’re
targeting with your library into your library’s <dependencyManagement> section.
That will allow you to use any dependency managed by Spring Boot without having to
specify its version.
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
Nils.
P.S. I notice your old POM uses Log4J 2.15.0, which is vulnerable to the pretty
serious Log4Shell vulnerabilities.
