Re: improving the Maven BOM pattern

[Tamás Cservenák]

So to say, in a project that for example depends on maven-core ONLY, I
would assume my transitive deps would be good
But, in a moment I have OTHER direct dependendencies, that MAY have
overlapping transitive dependencies with anything overlapping with those
from maven-core, things go south...

T

On Thu, Jun 15, 2023 at 8:17 AM Tamás Cservenák  wrote:

> Am exactly along Thomas lines...
>
> And even tried to backport Maven 4 BOM to Maven 3.9.x, just to figure out
> that as it stands
> https://github.com/apache/maven/blob/master/maven-bom/pom.xml
> (modules only, so for consumer "first level deps") makes no sense to me.
>
> T
>
> On Thu, Jun 15, 2023 at 8:12 AM Thomas Broyer  wrote:
>
>> I must say I haven't seen any project using the approach described in the
>> Maven doc.
>>
>> Most projects I've seen use the root POM as both the aggregator POM and
>> the
>> parent POM, and have their BOM in a submodule. Sometimes the root POM is
>> only the aggregator and the parent POM is a submodule as well.
>>
>> Actually the biggest problem with BOMs is that you want them to have a
>> parent to share all deployment plugins configuration, but without the
>> dependency management of the project, so other submodules would have a
>> different parent with those same plugins, possibly other plugins, and
>> dependency management (importing the BOM and, in your example, Guava).
>> This can quickly lead to many POM/submodules just to split plugin
>> configuration and dependency mangement and the BOM and the parent and…
>>
>> Le jeu. 15 juin 2023 à 01:05, Garret Wilson  a
>> écrit :
>>
>> > Hi, everyone. I understand this list to be a general forum for Apache
>> > Maven users, so as such I'm sharing some ideas I've had related to BOMs.
>> >
>> > Over the years I've changed how I define "Bill of Material" POMs for my
>> > large, aggregated projects. Recently I've settled on a pattern which I
>> > feel is a refinement of the official Maven approach
>> > <
>> >
>> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
>> >
>> >
>> > for putting together a BOM. I've described the technique in my blog post
>> > I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
>> > > >.
>> > Here's a summary.
>> >
>> > Assuming we have a project `com.example:…` with aggregated subprojects
>> > `com.example:foo` and `com.example:bar`, my technique uses the following
>> > directory structure:
>> >
>> > |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └──
>> pom.xml|
>> >
>> > Interestingly the top-level BOM aggregates all three POMs: the two
>> > submodule POMs as well as `parent-pom.xml` in the project root
>> > directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
>> > their parent.
>> >
>> > I see this bringing a couple of benefits over the official approach in
>> > the documentation:
>> >
>> >   * Aggregated modules are easy to find—in the top-level POM where they
>> > logically should be.
>> >   * Other project dependencies and configurations are located nearby, in
>> > the `parent-pom.xml` file in the same project root directory as the
>> > BOM, not relegated to a separate subdirectory.
>> >
>> > The post goes into much more detail explaining the differences, with
>> > example of the POM contents.
>> >
>> > I'd be interested in feedback on this technique if you have any
>> > comments—especially if you find a flaw in this approach.
>> >
>> > Best,
>> >
>> > Garret
>> >
>>
>

Re: improving the Maven BOM pattern

[Tamás Cservenák]

Am exactly along Thomas lines...

And even tried to backport Maven 4 BOM to Maven 3.9.x, just to figure out
that as it stands
https://github.com/apache/maven/blob/master/maven-bom/pom.xml
(modules only, so for consumer "first level deps") makes no sense to me.

T

On Thu, Jun 15, 2023 at 8:12 AM Thomas Broyer  wrote:

> I must say I haven't seen any project using the approach described in the
> Maven doc.
>
> Most projects I've seen use the root POM as both the aggregator POM and the
> parent POM, and have their BOM in a submodule. Sometimes the root POM is
> only the aggregator and the parent POM is a submodule as well.
>
> Actually the biggest problem with BOMs is that you want them to have a
> parent to share all deployment plugins configuration, but without the
> dependency management of the project, so other submodules would have a
> different parent with those same plugins, possibly other plugins, and
> dependency management (importing the BOM and, in your example, Guava).
> This can quickly lead to many POM/submodules just to split plugin
> configuration and dependency mangement and the BOM and the parent and…
>
> Le jeu. 15 juin 2023 à 01:05, Garret Wilson  a
> écrit :
>
> > Hi, everyone. I understand this list to be a general forum for Apache
> > Maven users, so as such I'm sharing some ideas I've had related to BOMs.
> >
> > Over the years I've changed how I define "Bill of Material" POMs for my
> > large, aggregated projects. Recently I've settled on a pattern which I
> > feel is a refinement of the official Maven approach
> > <
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms
> >
> >
> > for putting together a BOM. I've described the technique in my blog post
> > I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
> >  >.
> > Here's a summary.
> >
> > Assuming we have a project `com.example:…` with aggregated subprojects
> > `com.example:foo` and `com.example:bar`, my technique uses the following
> > directory structure:
> >
> > |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └──
> pom.xml|
> >
> > Interestingly the top-level BOM aggregates all three POMs: the two
> > submodule POMs as well as `parent-pom.xml` in the project root
> > directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
> > their parent.
> >
> > I see this bringing a couple of benefits over the official approach in
> > the documentation:
> >
> >   * Aggregated modules are easy to find—in the top-level POM where they
> > logically should be.
> >   * Other project dependencies and configurations are located nearby, in
> > the `parent-pom.xml` file in the same project root directory as the
> > BOM, not relegated to a separate subdirectory.
> >
> > The post goes into much more detail explaining the differences, with
> > example of the POM contents.
> >
> > I'd be interested in feedback on this technique if you have any
> > comments—especially if you find a flaw in this approach.
> >
> > Best,
> >
> > Garret
> >
>

Re: improving the Maven BOM pattern

[Thomas Broyer]

I must say I haven't seen any project using the approach described in the
Maven doc.

Most projects I've seen use the root POM as both the aggregator POM and the
parent POM, and have their BOM in a submodule. Sometimes the root POM is
only the aggregator and the parent POM is a submodule as well.

Actually the biggest problem with BOMs is that you want them to have a
parent to share all deployment plugins configuration, but without the
dependency management of the project, so other submodules would have a
different parent with those same plugins, possibly other plugins, and
dependency management (importing the BOM and, in your example, Guava).
This can quickly lead to many POM/submodules just to split plugin
configuration and dependency mangement and the BOM and the parent and…

Le jeu. 15 juin 2023 à 01:05, Garret Wilson  a
écrit :

> Hi, everyone. I understand this list to be a general forum for Apache
> Maven users, so as such I'm sharing some ideas I've had related to BOMs.
>
> Over the years I've changed how I define "Bill of Material" POMs for my
> large, aggregated projects. Recently I've settled on a pattern which I
> feel is a refinement of the official Maven approach
> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>
>
> for putting together a BOM. I've described the technique in my blog post
> I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
> .
> Here's a summary.
>
> Assuming we have a project `com.example:…` with aggregated subprojects
> `com.example:foo` and `com.example:bar`, my technique uses the following
> directory structure:
>
> |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|
>
> Interestingly the top-level BOM aggregates all three POMs: the two
> submodule POMs as well as `parent-pom.xml` in the project root
> directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
> their parent.
>
> I see this bringing a couple of benefits over the official approach in
> the documentation:
>
>   * Aggregated modules are easy to find—in the top-level POM where they
> logically should be.
>   * Other project dependencies and configurations are located nearby, in
> the `parent-pom.xml` file in the same project root directory as the
> BOM, not relegated to a separate subdirectory.
>
> The post goes into much more detail explaining the differences, with
> example of the POM contents.
>
> I'd be interested in feedback on this technique if you have any
> comments—especially if you find a flaw in this approach.
>
> Best,
>
> Garret
>

Re: improving the Maven BOM pattern

[Garret Wilson]

On 6/14/2023 5:53 PM, Gary Gregory wrote:

I am wondering if you've looked at the CycloneDx and SPDX Maven plugins?

These two seem to be the most used ATM for SBOMs.

Gary


I had never heard of these plugins or of SBOMs. I did a quick bit of 
research; according to [How to create SBOMs in Java with Maven and 
Gradle](https://snyk.io/blog/create-sboms-java-maven-gradle/):


> But be careful to not confuse an SBOM with Maven's Bill Of Materials 
(BOM). In Maven, a BOM is a special kind of POM file where we can 
centralize dependencies for an application. In most cases, these 
dependencies work well together and should be used as a set, like we see 
in BOMs used in Spring.


> An SBOM is something you create next to your application, so any user 
or client has a uniform way to find out what your application is using 
under the hood.


So an SBOM seems to be different than the Maven BOM I was talking about, 
with a different purpose. But thanks for the pointer—always nice to 
learn about new things.


Garret


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: improving the Maven BOM pattern

[Gary Gregory]

I am wondering if you've looked at the CycloneDx and SPDX Maven plugins?

These two seem to be the most used ATM for SBOMs.

Gary

On Wed, Jun 14, 2023, 19:05 Garret Wilson  wrote:

> Hi, everyone. I understand this list to be a general forum for Apache
> Maven users, so as such I'm sharing some ideas I've had related to BOMs.
>
> Over the years I've changed how I define "Bill of Material" POMs for my
> large, aggregated projects. Recently I've settled on a pattern which I
> feel is a refinement of the official Maven approach
> <
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#bill-of-materials-bom-poms>
>
> for putting together a BOM. I've described the technique in my blog post
> I published today: /Improving the Maven Bill of Materials (BOM) Pattern/
> .
> Here's a summary.
>
> Assuming we have a project `com.example:…` with aggregated subprojects
> `com.example:foo` and `com.example:bar`, my technique uses the following
> directory structure:
>
> |pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|
>
> Interestingly the top-level BOM aggregates all three POMs: the two
> submodule POMs as well as `parent-pom.xml` in the project root
> directory. The two submodules `foo` and `bar` use `parent-pom.xml` as
> their parent.
>
> I see this bringing a couple of benefits over the official approach in
> the documentation:
>
>   * Aggregated modules are easy to find—in the top-level POM where they
> logically should be.
>   * Other project dependencies and configurations are located nearby, in
> the `parent-pom.xml` file in the same project root directory as the
> BOM, not relegated to a separate subdirectory.
>
> The post goes into much more detail explaining the differences, with
> example of the POM contents.
>
> I'd be interested in feedback on this technique if you have any
> comments—especially if you find a flaw in this approach.
>
> Best,
>
> Garret
>

Re: improving the Maven BOM pattern

[Garret Wilson]

The file tree didn't go across the list so well. Here's another try below:

On 6/14/2023 4:05 PM, Garret Wilson wrote:

…

Over the years I've changed how I define "Bill of Material" POMs for 
my large, aggregated projects. Recently I've settled on a pattern 
which I feel is a refinement of the official Maven approach 
 
for putting together a BOM. I've described the technique in my blog 
post I published today: /Improving the Maven Bill of Materials (BOM) 
Pattern/ 
. 
Here's a summary.


Assuming we have a project `com.example:…` with aggregated subprojects 
`com.example:foo` and `com.example:bar`, my technique uses the 
following directory structure:


pom.xml
parent-pom.xml
├── foo/
│   └── pom.xml
└── bar/
    └── pom.xml


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

improving the Maven BOM pattern

[Garret Wilson]

Hi, everyone. I understand this list to be a general forum for Apache 
Maven users, so as such I'm sharing some ideas I've had related to BOMs.


Over the years I've changed how I define "Bill of Material" POMs for my 
large, aggregated projects. Recently I've settled on a pattern which I 
feel is a refinement of the official Maven approach 
 
for putting together a BOM. I've described the technique in my blog post 
I published today: /Improving the Maven Bill of Materials (BOM) Pattern/ 
. 
Here's a summary.


Assuming we have a project `com.example:…` with aggregated subprojects 
`com.example:foo` and `com.example:bar`, my technique uses the following 
directory structure:


|pom.xml (BOM) parent-pom.xml ├── foo/ │ └── pom.xml └── bar/ └── pom.xml|

Interestingly the top-level BOM aggregates all three POMs: the two 
submodule POMs as well as `parent-pom.xml` in the project root 
directory. The two submodules `foo` and `bar` use `parent-pom.xml` as 
their parent.


I see this bringing a couple of benefits over the official approach in 
the documentation:


 * Aggregated modules are easy to find—in the top-level POM where they
   logically should be.
 * Other project dependencies and configurations are located nearby, in
   the `parent-pom.xml` file in the same project root directory as the
   BOM, not relegated to a separate subdirectory.

The post goes into much more detail explaining the differences, with 
example of the POM contents.


I'd be interested in feedback on this technique if you have any 
comments—especially if you find a flaw in this approach.


Best,

Garret