Building Maven Under JDK 24

2025-03-19 Thread Mark Derricutt 
Whilst Maven 4 is targeting Java 17, I see the build doesn’t seem to work
under Java 24:

[INFO] --- sisu:0.9.0.M3:main-index (index-project) @ maven-model-builder
---
[INFO]

[INFO] Reactor Summary for Apache Maven 4.0.0-rc-4-SNAPSHOT:
[INFO]
[INFO] Apache Maven ... SUCCESS [
 1.062 s]
[INFO] Maven 4 API  SUCCESS [
 0.038 s]
[INFO] Maven 4 API :: Meta annotations  SUCCESS [
 0.587 s]
[INFO] Maven 4 API :: Dependency Injection  SUCCESS [
 0.274 s]
[INFO] Maven 4 API :: XML . SUCCESS [
 0.113 s]
[INFO] Maven 4 API :: Model ... SUCCESS [
 1.013 s]
[INFO] Maven 4 API :: Plugin .. SUCCESS [
 0.932 s]
[INFO] Maven 4 API :: Settings  SUCCESS [
 0.846 s]
[INFO] Maven 4 API :: Toolchain ... SUCCESS [
 0.156 s]
[INFO] Maven 4 API :: Repository Metadata . SUCCESS [
 0.125 s]
[INFO] Maven 4 API :: Core  SUCCESS [
 2.658 s]
[INFO] Maven 4 API :: SPI . SUCCESS [
 0.114 s]
[INFO] Maven 4 API :: CLI . SUCCESS [
 0.211 s]
[INFO] Maven 4 Implementation Modules . SUCCESS [
 0.020 s]
[INFO] Maven 4 XML Implementation . SUCCESS [
 1.064 s]
[INFO] Maven 4 Model Support .. SUCCESS [
 0.541 s]
[INFO] Maven 4 Dependency Injection ... SUCCESS [
 1.059 s]
[INFO] Maven 4 API Implementation . SUCCESS [
12.464 s]
[INFO] Maven 4 JLine integration .. SUCCESS [
 0.133 s]
[INFO] Maven 4 Logging  SUCCESS [
 0.869 s]
[INFO] Maven Compatibility Modules  SUCCESS [
 0.024 s]
[INFO] Maven Artifact . SUCCESS [
 1.022 s]
[INFO] Maven Model  SUCCESS [
 1.382 s]
[INFO] Maven Builder Support (deprecated) . SUCCESS [
 0.725 s]
[INFO] Maven Model Builder (deprecated) ... FAILURE [
 1.037 s]
[INFO] Maven 3 Plugin API . SKIPPED
[INFO] Maven Repository Metadata Model  SKIPPED
[INFO] Maven Settings . SKIPPED
[INFO] Maven Toolchain Model .. SKIPPED
[INFO] Maven Toolchain Builder (deprecated) ... SKIPPED
[INFO] Maven 4 Core ... SKIPPED
[INFO] Maven Settings Builder (deprecated)  SKIPPED
[INFO] Maven Artifact Resolver Provider (deprecated) .. SKIPPED
[INFO] Maven Compat (deprecated) .. SKIPPED
[INFO] Maven 4 CLI  SKIPPED
[INFO] Maven Embedder (deprecated)  SKIPPED
[INFO] Apache Maven Distribution .. SKIPPED
[INFO] Maven 4 Executor ... SKIPPED
[INFO]

[INFO] BUILD FAILURE
[INFO]

[INFO] Total time:  31.536 s
[INFO] Finished at: 2025-03-20T09:55:14+13:00
[INFO]

[ERROR] Failed to execute goal
org.eclipse.sisu:sisu-maven-plugin:0.9.0.M3:main-index (index-project) on
project maven-model-builder: Execution index-project of goal
org.eclipse.sisu:sisu-maven-plugin:0.9.0.M3:main-index failed: Problem
scanning
file:/Users/amrk/IdeaProjects/upstream/maven/compat/maven-model-builder/target/classes/org/apache/maven/utils/Os.class:
Problem scanning jrt:/java.base/java/lang/Deprecated.class: Unsupported
class file major version 68 -> [Help 1]
[ERROR]


This is trying to build Guillaume Nodet’s mixin branch, which comes
off 4.0.0-rc-4-SNAPSHOT.

Mark


-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Building Maven Under JDK 24

2025-03-19 Thread Romain Manni-Bucau 
Hi,

did you try upgrading asm in plugin deps?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le mer. 19 mars 2025 à 22:02, Mark Derricutt  a écrit :

> Whilst Maven 4 is targeting Java 17, I see the build doesn’t seem to work
> under Java 24:
>
> [INFO] --- sisu:0.9.0.M3:main-index (index-project) @ maven-model-builder
> ---
> [INFO]
> 
> [INFO] Reactor Summary for Apache Maven 4.0.0-rc-4-SNAPSHOT:
> [INFO]
> [INFO] Apache Maven ... SUCCESS [
>  1.062 s]
> [INFO] Maven 4 API  SUCCESS [
>  0.038 s]
> [INFO] Maven 4 API :: Meta annotations  SUCCESS [
>  0.587 s]
> [INFO] Maven 4 API :: Dependency Injection  SUCCESS [
>  0.274 s]
> [INFO] Maven 4 API :: XML . SUCCESS [
>  0.113 s]
> [INFO] Maven 4 API :: Model ... SUCCESS [
>  1.013 s]
> [INFO] Maven 4 API :: Plugin .. SUCCESS [
>  0.932 s]
> [INFO] Maven 4 API :: Settings  SUCCESS [
>  0.846 s]
> [INFO] Maven 4 API :: Toolchain ... SUCCESS [
>  0.156 s]
> [INFO] Maven 4 API :: Repository Metadata . SUCCESS [
>  0.125 s]
> [INFO] Maven 4 API :: Core  SUCCESS [
>  2.658 s]
> [INFO] Maven 4 API :: SPI . SUCCESS [
>  0.114 s]
> [INFO] Maven 4 API :: CLI . SUCCESS [
>  0.211 s]
> [INFO] Maven 4 Implementation Modules . SUCCESS [
>  0.020 s]
> [INFO] Maven 4 XML Implementation . SUCCESS [
>  1.064 s]
> [INFO] Maven 4 Model Support .. SUCCESS [
>  0.541 s]
> [INFO] Maven 4 Dependency Injection ... SUCCESS [
>  1.059 s]
> [INFO] Maven 4 API Implementation . SUCCESS [
> 12.464 s]
> [INFO] Maven 4 JLine integration .. SUCCESS [
>  0.133 s]
> [INFO] Maven 4 Logging  SUCCESS [
>  0.869 s]
> [INFO] Maven Compatibility Modules  SUCCESS [
>  0.024 s]
> [INFO] Maven Artifact . SUCCESS [
>  1.022 s]
> [INFO] Maven Model  SUCCESS [
>  1.382 s]
> [INFO] Maven Builder Support (deprecated) . SUCCESS [
>  0.725 s]
> [INFO] Maven Model Builder (deprecated) ... FAILURE [
>  1.037 s]
> [INFO] Maven 3 Plugin API . SKIPPED
> [INFO] Maven Repository Metadata Model  SKIPPED
> [INFO] Maven Settings . SKIPPED
> [INFO] Maven Toolchain Model .. SKIPPED
> [INFO] Maven Toolchain Builder (deprecated) ... SKIPPED
> [INFO] Maven 4 Core ... SKIPPED
> [INFO] Maven Settings Builder (deprecated)  SKIPPED
> [INFO] Maven Artifact Resolver Provider (deprecated) .. SKIPPED
> [INFO] Maven Compat (deprecated) .. SKIPPED
> [INFO] Maven 4 CLI  SKIPPED
> [INFO] Maven Embedder (deprecated)  SKIPPED
> [INFO] Apache Maven Distribution .. SKIPPED
> [INFO] Maven 4 Executor ... SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time:  31.536 s
> [INFO] Finished at: 2025-03-20T09:55:14+13:00
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.eclipse.sisu:sisu-maven-plugin:0.9.0.M3:main-index (index-project) on
> project maven-model-builder: Execution index-project of goal
> org.eclipse.sisu:sisu-maven-plugin:0.9.0.M3:main-index failed: Problem
> scanning
>
> file:/Users/amrk/IdeaProjects/upstream/maven/compat/maven-model-builder/target/classes/org/apache/maven/utils/Os.class:
> Problem scanning jrt:/java.base/java/lang/Deprecated.class: Unsupported
> class file major version 68 -> [Help 1]
> [ERROR]
>
>
> This is trying to build Guillaume Nodet’s mixin branch, which comes
> off 4.0.0-rc-4-SNAPSHOT.
>
> Mark
>
>
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>

Re: Building Maven Under JDK 24

2025-03-19 Thread Mark Derricutt 
 On 20 Mar 2025 at 10:04:24 AM, Romain Manni-Bucau 
wrote:

> did you try upgrading asm in plugin deps?
>

Nope - but a cursory glance shows asm 9.7.1 being used, which is the
current version.
-- 
"Great artists are extremely selfish and arrogant things" — Steven Wilson,
Porcupine Tree

Re: Building Maven Under JDK 24

2025-03-19 Thread Mark Derricutt 
On 20 Mar 2025 at 7:12:40 PM, Romain Manni-Bucau 
wrote:

> Looks like the error says the opposite, did you check the plugin asm
> version and not maven one?
>
>
>
Looks like the build is using 0.9.0.M3 of the issue-maven-plugin, which
includes and embeded version of asm 9.6:


https://github.com/eclipse-sisu/sisu-project/pull/95/commits/c239adfad8eec92b85a33a431d4c5e2a4eff2dc7

So I guess that needs updating and a new sisu plugin releasing.  Will take
a look at patching that and trying it.

Mark

Re: Building Maven Under JDK 24

2025-03-19 Thread Romain Manni-Bucau 
Looks like the error says the opposite, did you check the plugin asm
version and not maven one?

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le mer. 19 mars 2025 à 23:36, Mark Derricutt  a écrit :

>  On 20 Mar 2025 at 10:04:24 AM, Romain Manni-Bucau 
> wrote:
>
> > did you try upgrading asm in plugin deps?
> >
>
> Nope - but a cursory glance shows asm 9.7.1 being used, which is the
> current version.
> --
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree
>

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Tamás Cservenák 
Howdy,

some tooling already exists:
gav-dm-tree: https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
gav-dm-list: https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
and the new "flatten bom" mojo.

And my proposal is to "pre-digest" the BOM, not any BOM you consume,
just those super-BOMs that have deep (import) hierarchy (look at
dm-tree and dm-list outputs above).
While I did flatten-BOM, I was also tinkering to do some "merge" or
alike, but realized that:
* simple tool is better than complex
* flatten "solves" the problem for big BOMs (for example, using this
tool for Junit BOM makes no sense)
* the rest of how to "fit" flattened BOM becomes simpler, as now that
they are flat, you DO have control.
* generation of flat BOM should be consistent: for same BOM GAV the
output should be SAME -- just keep it simple; if we add knobs like
which version to select, user could easily shoot himself in the foot

The goal of new mojo is to flatten input BOM and do it consistently:
if you point it at same BOM, your output is same as before (sans
possible coordinate change of the emitted BOM itself)

T

On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy  wrote:
>
> FTR Jira issues
> https://issues.apache.org/jira/browse/MNG-7906
> https://issues.apache.org/jira/browse/MNG-7854
> https://issues.apache.org/jira/browse/MPH-183
> and all linked issues
>
> I don't know how this is relates with bom packaging in Maven 4
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs
>
>
> The fact that this dependencyManagement import happens at effective model
> building stage, and not during dependency resolution, created specific
> complexity on how to analyze conflict resolution, report (not possible to
> dependency-tree -Dverbose), and have solutions for end-user to override
> default conflict resolution result.
>
> I dislike the currently non-actionable WARNINGs, particularly when actionable
> solution when a conflict resolution does not bring you the result you want, 
> you
> can override by declaring a dependencyManagement entry before import.
>
> On what conflict resolution algorithm is in place, should we change it, to
> which one: discussion never went to a solid proposition.
>
> Notice that we don't have great usable documentation on that feature and its
> problems: just long discussions in Jira issues.
>
> I discover here what I'll call a new proposal from Tamasz:
> 1. promote avoiding multiple conflicting dependencyManagement imports, as they
> are hard to analyze
> 2. promote a merging tool where these conflicts can be worked on and choices
> done: first wins? last wins? (personal addition) greater wins?
> I'm sure some reporting on BOM POMs could also be interesting, given they
> started small and easy to get when used individually, but went complex when
> people started to assemble them
>
> HTH
>
> Hervé
>
> Le mardi 18 mars 2025, 18:47:49 CET Tamás Cservenák a écrit :
> > Howdy,
> >
> > Problem with BOM imports is that they were never "done done" in Maven
> > 3.x time-frame, and they work the total opposite to everything else in
> > Maven (think dependencies, as Delany says), hence they work in "non
> > Maven way", not intuitive way, and tend to cause (usually bad)
> > surprises. Sadly, they are overused in many projects, especially with
> > recursive-imports happening. Maven 4 just tries to warn you about
> > these, when a dependency is "stepping on toe" of another dependency,
> > but again, as a consumer, you have not much control over it.
> > Personally, I'd avoid using BOMs like these, and I'd preferably
> > generate my own.
> >
> > In short, BOMs should be
> > * flat (no recursive import)
> > * generated
> > * curated
> >
> > Sadly, with BOM you point at, none of these stands. Maven 4 tries to
> > "fix" things, that's all. Same as with CI Friendly support, this is
> > just yet another "incomplete" implementation.
> >
> > Personally, I'd prevent or better REMOVE recursive import capability
> > (so dep type=pom scope=import would NOT recursively import anything)
> > -- just to force them to be flat for start.
> > BOMs should be curated and generated (and flat).
> >
> > For these cases:
> > * take a peek at BOM generator (used in Maven build as well):
> > https://github.com/maveniverse/bom-builder-maven-plugin
> > * took a stab for a tool I'd use: BOM flatten, try it
> > out!https://github.com/maveniverse/toolbox/pull/180
> >
> > Regarding flatten-BOM: again, perso I'd NOT use BOM specified by you,
> > but instead I'd deploy "flattened" BOM under my namespace (see gist
> > example) and use that. Given it is generated, you can just generate
> > new for any new version out there,
> >
> >
> > My 5 cents
> > T
> >
> > On Mon, Mar 17, 2025 at 8:43 PM Karl Heinz Marbaise
> >
> >  wrote:
> > > Hi to all,
> > >
> > > currently I'm trying to build a simple spring boot application which
> > > uses a BOM for spring-boot-dependencies..
> >

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Hervé Boutemy 
FTR Jira issues 
https://issues.apache.org/jira/browse/MNG-7906
https://issues.apache.org/jira/browse/MNG-7854
https://issues.apache.org/jira/browse/MPH-183
and all linked issues

I don't know how this is relates with bom packaging in Maven 4
https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs


The fact that this dependencyManagement import happens at effective model 
building stage, and not during dependency resolution, created specific 
complexity on how to analyze conflict resolution, report (not possible to 
dependency-tree -Dverbose), and have solutions for end-user to override 
default conflict resolution result.

I dislike the currently non-actionable WARNINGs, particularly when actionable 
solution when a conflict resolution does not bring you the result you want, you 
can override by declaring a dependencyManagement entry before import.

On what conflict resolution algorithm is in place, should we change it, to 
which one: discussion never went to a solid proposition.

Notice that we don't have great usable documentation on that feature and its 
problems: just long discussions in Jira issues.

I discover here what I'll call a new proposal from Tamasz:
1. promote avoiding multiple conflicting dependencyManagement imports, as they 
are hard to analyze
2. promote a merging tool where these conflicts can be worked on and choices 
done: first wins? last wins? (personal addition) greater wins?
I'm sure some reporting on BOM POMs could also be interesting, given they 
started small and easy to get when used individually, but went complex when 
people started to assemble them

HTH

Hervé

Le mardi 18 mars 2025, 18:47:49 CET Tamás Cservenák a écrit :
> Howdy,
> 
> Problem with BOM imports is that they were never "done done" in Maven
> 3.x time-frame, and they work the total opposite to everything else in
> Maven (think dependencies, as Delany says), hence they work in "non
> Maven way", not intuitive way, and tend to cause (usually bad)
> surprises. Sadly, they are overused in many projects, especially with
> recursive-imports happening. Maven 4 just tries to warn you about
> these, when a dependency is "stepping on toe" of another dependency,
> but again, as a consumer, you have not much control over it.
> Personally, I'd avoid using BOMs like these, and I'd preferably
> generate my own.
> 
> In short, BOMs should be
> * flat (no recursive import)
> * generated
> * curated
> 
> Sadly, with BOM you point at, none of these stands. Maven 4 tries to
> "fix" things, that's all. Same as with CI Friendly support, this is
> just yet another "incomplete" implementation.
> 
> Personally, I'd prevent or better REMOVE recursive import capability
> (so dep type=pom scope=import would NOT recursively import anything)
> -- just to force them to be flat for start.
> BOMs should be curated and generated (and flat).
> 
> For these cases:
> * take a peek at BOM generator (used in Maven build as well):
> https://github.com/maveniverse/bom-builder-maven-plugin
> * took a stab for a tool I'd use: BOM flatten, try it
> out!https://github.com/maveniverse/toolbox/pull/180
> 
> Regarding flatten-BOM: again, perso I'd NOT use BOM specified by you,
> but instead I'd deploy "flattened" BOM under my namespace (see gist
> example) and use that. Given it is generated, you can just generate
> new for any new version out there,
> 
> 
> My 5 cents
> T
> 
> On Mon, Mar 17, 2025 at 8:43 PM Karl Heinz Marbaise
> 
>  wrote:
> > Hi to all,
> > 
> > currently I'm trying to build a simple spring boot application which
> > uses a BOM for spring-boot-dependencies..
> > 
> >
> >
> >  org.springframework.boot
> >  spring-boot-dependencies
> >  3.3.3
> >  import
> >  pom
> >
> >
> > 
> > So based on the releases of JUnit Jupiter, Mockito etc.
> > I define the BOM's of JUnit Jupiter and Mockito (and others; only
> > excerpts shown here) before the spring boot dependencies like this,
> > because I want to use newer versions, than spring-boot-dependencies
> > defines.> 
> >
> >
> >  
> >  
> >
> >
> >  org.junit
> >  junit-bom
> >  5.12.1
> >  pom
> >  import
> >
> >
> >
> >
> >  org.mockito
> >  mockito-bom
> >  5.16.1
> >  import
> >  pom
> >
> >
> >..
> >
> >
> >  org.springframework.boot
> >  spring-boot-dependencies
> >  ${spring.boot.version}
> >  import
> >  pom
> >
> >
> >..
> >  
> >  
> >
> >
> > 
> > If I build the project Maven 4.0.0-rc3 I got a bunch of warnings like
> > this:
> > mvn clean -e
> > [INFO] Error stacktraces are turned on.
> > [INFO]
> > .
> > [INFO] Scanning for projects...
> > [WARNING]
> > [WARNING] 26 problems were encount

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Tamás Cservenák 
Howdy,

BOMs are "good things" when authored and used properly.

Problem begins when BOMs authors start adding import statements to
their authored BOMs. BOMs should be _flat_.

Problem explained:
* I as consumer "delegate" dep control to library I want to use, BUT
* library BOM "delegate" dep control to third library (those it imports)
So I, as a consumer, am "two delegations away" from the problem(s)
source. Is out of my reach.

In a moment BOM contains import(s), it opens a possibility (does not
have to!) of worms with conflicts, that are "non actionable warnings".
Moreover, if my project needs two "recursive BOMs" for some reason,
problems are just piling up.

And to be no misunderstanding: NOTHING changed between Maven 3 and
Maven 4 re "problem".
The ONLY change in Maven 4 is that it is not silent anymore, it warns.
And users cannot do anything about it, this is true for Maven 3 and Maven 4.

Hence, to repeat my stance: personally, I'd never use these
"problematic" BOMs in my projects,
instead I'd "preprocess" them (flatten) as in that moment I (as
consumer) am back in control:
I can apply exclusions (in Maven 4), apply ordering and overrides I want, etc.

T

On Wed, Mar 19, 2025 at 1:46 PM Romain Manni-Bucau
 wrote:
>
> Can we step back a sec, what does bom bring that is not solved without?
> Dependency resolution is perfectly handled with type=pom (without
> scope=import), reusability with multiple scope is quite trivial with a
> property for the version and potentially the whole gav.
> At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO.
>
> Romain Manni-Bucau
> @rmannibucau  | .NET Blog
>  | Blog  | 
> Old
> Blog  | Github
>  | LinkedIn
>  | Book
> 
>
>
> Le mer. 19 mars 2025 à 11:51, Tamás Cservenák  a
> écrit :
>
> > Howdy,
> >
> > some tooling already exists:
> > gav-dm-tree:
> > https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
> > gav-dm-list
> > :
> > https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
> > and the new "flatten bom" mojo.
> >
> > And my proposal is to "pre-digest" the BOM, not any BOM you consume,
> > just those super-BOMs that have deep (import) hierarchy (look at
> > dm-tree and dm-list outputs above).
> > While I did flatten-BOM, I was also tinkering to do some "merge" or
> > alike, but realized that:
> > * simple tool is better than complex
> > * flatten "solves" the problem for big BOMs (for example, using this
> > tool for Junit BOM makes no sense)
> > * the rest of how to "fit" flattened BOM becomes simpler, as now that
> > they are flat, you DO have control.
> > * generation of flat BOM should be consistent: for same BOM GAV the
> > output should be SAME -- just keep it simple; if we add knobs like
> > which version to select, user could easily shoot himself in the foot
> >
> > The goal of new mojo is to flatten input BOM and do it consistently:
> > if you point it at same BOM, your output is same as before (sans
> > possible coordinate change of the emitted BOM itself)
> >
> > T
> >
> > On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy  wrote:
> > >
> > > FTR Jira issues
> > > https://issues.apache.org/jira/browse/MNG-7906
> > > https://issues.apache.org/jira/browse/MNG-7854
> > > https://issues.apache.org/jira/browse/MPH-183
> > > and all linked issues
> > >
> > > I don't know how this is relates with bom packaging in Maven 4
> > >
> > https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs
> > >
> > >
> > > The fact that this dependencyManagement import happens at effective model
> > > building stage, and not during dependency resolution, created specific
> > > complexity on how to analyze conflict resolution, report (not possible to
> > > dependency-tree -Dverbose), and have solutions for end-user to override
> > > default conflict resolution result.
> > >
> > > I dislike the currently non-actionable WARNINGs, particularly when
> > actionable
> > > solution when a conflict resolution does not bring you the result you
> > want, you
> > > can override by declaring a dependencyManagement entry before import.
> > >
> > > On what conflict resolution algorithm is in place, should we change it,
> > to
> > > which one: discussion never went to a solid proposition.
> > >
> > > Notice that we don't have great usable documentation on that feature and
> > its
> > > problems: just long discussions in Jira issues.
> > >
> > > I discover here what I'll call a new proposal from Tamasz:
> > > 1. promote avoiding multiple conflicting dependencyManagement imports,
> > as they
> > > are hard to analyze
> > > 2. promote a merging t

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Romain Manni-Bucau 
Le mer. 19 mars 2025 à 13:59, Tamás Cservenák  a
écrit :

> Howdy,
>
> BOMs are "good things" when authored and used properly.
>
>
Not really, it is if you have a single one but as soon as it needs 3rd
party it is a mess even if well written or you need a bom for all project
and flatten all your dependencies in dependencies management.
So I really think it was a good bad idea, we can just assume it now and
deprecate the concept thanks to pom versions IMHO.


> Problem begins when BOMs authors start adding import statements to
> their authored BOMs. BOMs should be _flat_.


> Problem explained:
> * I as consumer "delegate" dep control to library I want to use, BUT
> * library BOM "delegate" dep control to third library (those it imports)
> So I, as a consumer, am "two delegations away" from the problem(s)
> source. Is out of my reach.
>
> In a moment BOM contains import(s), it opens a possibility (does not
> have to!) of worms with conflicts, that are "non actionable warnings".
> Moreover, if my project needs two "recursive BOMs" for some reason,
> problems are just piling up.
>
> And to be no misunderstanding: NOTHING changed between Maven 3 and
> Maven 4 re "problem".
> The ONLY change in Maven 4 is that it is not silent anymore, it warns.
> And users cannot do anything about it, this is true for Maven 3 and Maven
> 4.
>
> Hence, to repeat my stance: personally, I'd never use these
> "problematic" BOMs in my projects,
> instead I'd "preprocess" them (flatten) as in that moment I (as
> consumer) am back in control:
> I can apply exclusions (in Maven 4), apply ordering and overrides I want,
> etc.
>
> T
>
> On Wed, Mar 19, 2025 at 1:46 PM Romain Manni-Bucau
>  wrote:
> >
> > Can we step back a sec, what does bom bring that is not solved without?
> > Dependency resolution is perfectly handled with type=pom (without
> > scope=import), reusability with multiple scope is quite trivial with a
> > property for the version and potentially the whole gav.
> > At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  | .NET Blog
> >  | Blog 
> | Old
> > Blog  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
> >
> >
> > Le mer. 19 mars 2025 à 11:51, Tamás Cservenák  a
> > écrit :
> >
> > > Howdy,
> > >
> > > some tooling already exists:
> > > gav-dm-tree:
> > > https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
> > > gav-dm-list
> > > <
> https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bfgav-dm-list
> >:
> > > https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
> > > and the new "flatten bom" mojo.
> > >
> > > And my proposal is to "pre-digest" the BOM, not any BOM you consume,
> > > just those super-BOMs that have deep (import) hierarchy (look at
> > > dm-tree and dm-list outputs above).
> > > While I did flatten-BOM, I was also tinkering to do some "merge" or
> > > alike, but realized that:
> > > * simple tool is better than complex
> > > * flatten "solves" the problem for big BOMs (for example, using this
> > > tool for Junit BOM makes no sense)
> > > * the rest of how to "fit" flattened BOM becomes simpler, as now that
> > > they are flat, you DO have control.
> > > * generation of flat BOM should be consistent: for same BOM GAV the
> > > output should be SAME -- just keep it simple; if we add knobs like
> > > which version to select, user could easily shoot himself in the foot
> > >
> > > The goal of new mojo is to flatten input BOM and do it consistently:
> > > if you point it at same BOM, your output is same as before (sans
> > > possible coordinate change of the emitted BOM itself)
> > >
> > > T
> > >
> > > On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy 
> wrote:
> > > >
> > > > FTR Jira issues
> > > > https://issues.apache.org/jira/browse/MNG-7906
> > > > https://issues.apache.org/jira/browse/MNG-7854
> > > > https://issues.apache.org/jira/browse/MPH-183
> > > > and all linked issues
> > > >
> > > > I don't know how this is relates with bom packaging in Maven 4
> > > >
> > >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs
> > > >
> > > >
> > > > The fact that this dependencyManagement import happens at effective
> model
> > > > building stage, and not during dependency resolution, created
> specific
> > > > complexity on how to analyze conflict resolution, report (not
> possible to
> > > > dependency-tree -Dverbose), and have solutions for end-user to
> override
> > > > default conflict resolution result.
> > > >
> > > > I dislike the currently non-actionable WARNINGs, particularly when
> > > actionable
> > > > solution when a conflict resolution does not bring you t

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Romain Manni-Bucau 
Can we step back a sec, what does bom bring that is not solved without?
Dependency resolution is perfectly handled with type=pom (without
scope=import), reusability with multiple scope is quite trivial with a
property for the version and potentially the whole gav.
At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO.

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le mer. 19 mars 2025 à 11:51, Tamás Cservenák  a
écrit :

> Howdy,
>
> some tooling already exists:
> gav-dm-tree:
> https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
> gav-dm-list
> :
> https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
> and the new "flatten bom" mojo.
>
> And my proposal is to "pre-digest" the BOM, not any BOM you consume,
> just those super-BOMs that have deep (import) hierarchy (look at
> dm-tree and dm-list outputs above).
> While I did flatten-BOM, I was also tinkering to do some "merge" or
> alike, but realized that:
> * simple tool is better than complex
> * flatten "solves" the problem for big BOMs (for example, using this
> tool for Junit BOM makes no sense)
> * the rest of how to "fit" flattened BOM becomes simpler, as now that
> they are flat, you DO have control.
> * generation of flat BOM should be consistent: for same BOM GAV the
> output should be SAME -- just keep it simple; if we add knobs like
> which version to select, user could easily shoot himself in the foot
>
> The goal of new mojo is to flatten input BOM and do it consistently:
> if you point it at same BOM, your output is same as before (sans
> possible coordinate change of the emitted BOM itself)
>
> T
>
> On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy  wrote:
> >
> > FTR Jira issues
> > https://issues.apache.org/jira/browse/MNG-7906
> > https://issues.apache.org/jira/browse/MNG-7854
> > https://issues.apache.org/jira/browse/MPH-183
> > and all linked issues
> >
> > I don't know how this is relates with bom packaging in Maven 4
> >
> https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs
> >
> >
> > The fact that this dependencyManagement import happens at effective model
> > building stage, and not during dependency resolution, created specific
> > complexity on how to analyze conflict resolution, report (not possible to
> > dependency-tree -Dverbose), and have solutions for end-user to override
> > default conflict resolution result.
> >
> > I dislike the currently non-actionable WARNINGs, particularly when
> actionable
> > solution when a conflict resolution does not bring you the result you
> want, you
> > can override by declaring a dependencyManagement entry before import.
> >
> > On what conflict resolution algorithm is in place, should we change it,
> to
> > which one: discussion never went to a solid proposition.
> >
> > Notice that we don't have great usable documentation on that feature and
> its
> > problems: just long discussions in Jira issues.
> >
> > I discover here what I'll call a new proposal from Tamasz:
> > 1. promote avoiding multiple conflicting dependencyManagement imports,
> as they
> > are hard to analyze
> > 2. promote a merging tool where these conflicts can be worked on and
> choices
> > done: first wins? last wins? (personal addition) greater wins?
> > I'm sure some reporting on BOM POMs could also be interesting, given they
> > started small and easy to get when used individually, but went complex
> when
> > people started to assemble them
> >
> > HTH
> >
> > Hervé
> >
> > Le mardi 18 mars 2025, 18:47:49 CET Tamás Cservenák a écrit :
> > > Howdy,
> > >
> > > Problem with BOM imports is that they were never "done done" in Maven
> > > 3.x time-frame, and they work the total opposite to everything else in
> > > Maven (think dependencies, as Delany says), hence they work in "non
> > > Maven way", not intuitive way, and tend to cause (usually bad)
> > > surprises. Sadly, they are overused in many projects, especially with
> > > recursive-imports happening. Maven 4 just tries to warn you about
> > > these, when a dependency is "stepping on toe" of another dependency,
> > > but again, as a consumer, you have not much control over it.
> > > Personally, I'd avoid using BOMs like these, and I'd preferably
> > > generate my own.
> > >
> > > In short, BOMs should be
> > > * flat (no recursive import)
> > > * generated
> > > * curated
> > >
> > > Sadly, with BOM you point at, none of these stands. Maven 4 tries to
> > > "fix" things, that's all. Same as with CI Friendly support, this is
> > > just yet another "incomplete" imp

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Thomas Reinhardt 



If you need to digest a large 3rd party project you have to "know" all 
the internal versions of that project and/or its dependencies in some way.


For example we import com.fasterxml.jackson:jackson-parent which fixes 
versions of about 60 artifacts. Of course we don't use all of those but 
if we add e.g. some new transport mechanism, we are automatically 
getting the correct version. In this case it is somehow easy, as those 
versions are all (or at least most of them) the same.


A more complex example is org.wildfly:wildfly-ejb-client-bom which 
manages lots and lots of artifacts, all with different versions.


Arquillian is not even usable without 
org.jboss.arquillian:arquillian-bom I think, because it would be 
extremely time consuming to hunt down all the dependencies that you have 
to have in the right versions because there were breaking changes.


Of course some of those are just symptoms of projects that arguably 
should have been handled in a more simple way. But that is not the world 
we are living in and we have to use what is out there.


And honestly - I hate it when I have to use something with more than a 
couple of artifacts and there is no bom.


So with all due respect: please never even think about removing bom 
support. It is an essential feature for any non-toy project. If anything 
we (the maven users) need more support for boms. One thing that I am 
always missing is some kind of information like "I need xyz-1.2.3.jar 
and its dependencies, what are the coordinates for its bom". But I digress.



Thomas



On 19/03/2025 13:43, Romain Manni-Bucau wrote:

Can we step back a sec, what does bom bring that is not solved without?
Dependency resolution is perfectly handled with type=pom (without
scope=import), reusability with multiple scope is quite trivial with a
property for the version and potentially the whole gav.
At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO.

Romain Manni-Bucau
@rmannibucau  | .NET Blog
 | Blog  | Old
Blog  | Github
 | LinkedIn
 | Book



Le mer. 19 mars 2025 à 11:51, Tamás Cservenák  a
écrit :


Howdy,

some tooling already exists:
gav-dm-tree:
https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
gav-dm-list
:
https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
and the new "flatten bom" mojo.

And my proposal is to "pre-digest" the BOM, not any BOM you consume,
just those super-BOMs that have deep (import) hierarchy (look at
dm-tree and dm-list outputs above).
While I did flatten-BOM, I was also tinkering to do some "merge" or
alike, but realized that:
* simple tool is better than complex
* flatten "solves" the problem for big BOMs (for example, using this
tool for Junit BOM makes no sense)
* the rest of how to "fit" flattened BOM becomes simpler, as now that
they are flat, you DO have control.
* generation of flat BOM should be consistent: for same BOM GAV the
output should be SAME -- just keep it simple; if we add knobs like
which version to select, user could easily shoot himself in the foot

The goal of new mojo is to flatten input BOM and do it consistently:
if you point it at same BOM, your output is same as before (sans
possible coordinate change of the emitted BOM itself)

T

On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy  wrote:


FTR Jira issues
https://issues.apache.org/jira/browse/MNG-7906
https://issues.apache.org/jira/browse/MNG-7854
https://issues.apache.org/jira/browse/MPH-183
and all linked issues

I don't know how this is relates with bom packaging in Maven 4


https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Bill_of_Materials_.28BOM.29_POMs



The fact that this dependencyManagement import happens at effective model
building stage, and not during dependency resolution, created specific
complexity on how to analyze conflict resolution, report (not possible to
dependency-tree -Dverbose), and have solutions for end-user to override
default conflict resolution result.

I dislike the currently non-actionable WARNINGs, particularly when

actionable

solution when a conflict resolution does not bring you the result you

want, you

can override by declaring a dependencyManagement entry before import.

On what conflict resolution algorithm is in place, should we change it,

to

which one: discussion never went to a solid proposition.

Notice that we don't have great usable documentation on that feature and

its

problems: just long discussions in Jira issues.

I discover here what I'll call a new proposal from Tamasz:
1. promote avoiding multiple conflicting dependencyManagement imports,

as they

are har

Re: BOM / Imported BOM - Maven 4.0.0-rc3

2025-03-19 Thread Romain Manni-Bucau 
Le mer. 19 mars 2025 à 14:21, Thomas Reinhardt  a
écrit :

>
> If you need to digest a large 3rd party project you have to "know" all
> the internal versions of that project and/or its dependencies in some way.
>

Any reason to that? It was cleanly handled before bom without any issues.


>
> For example we import com.fasterxml.jackson:jackson-parent which fixes
> versions of about 60 artifacts. Of course we don't use all of those but
> if we add e.g. some new transport mechanism, we are automatically
> getting the correct version. In this case it is somehow easy, as those
> versions are all (or at least most of them) the same.
>

This is what transitive dependencies are giving you and for sibling
artifacts properties.

I would even highlight it is dangerous to do it the way you mention cause
in sibling modules you will inherit a version you do not want which
overrides transitive dependencies and breaks your module.


>
> A more complex example is org.wildfly:wildfly-ejb-client-bom which
> manages lots and lots of artifacts, all with different versions.
>

And it doesn't need bom, just type=pom.


>
> Arquillian is not even usable without
> org.jboss.arquillian:arquillian-bom I think, because it would be
> extremely time consuming to hunt down all the dependencies that you have
> to have in the right versions because there were breaking changes.
>

It is perfectly and you do not have to hunt anything.
Now, I can confirm using the bom breaks your project if you are using any
competing dependency.


>
> Of course some of those are just symptoms of projects that arguably
> should have been handled in a more simple way. But that is not the world
> we are living in and we have to use what is out there.
>
> And honestly - I hate it when I have to use something with more than a
> couple of artifacts and there is no bom.
>
> So with all due respect: please never even think about removing bom
> support. It is an essential feature for any non-toy project. If anything
> we (the maven users) need more support for boms. One thing that I am
> always missing is some kind of information like "I need xyz-1.2.3.jar
> and its dependencies, what are the coordinates for its bom". But I digress.
>

Don't get me wrong, I do not want to remove the hability to bring a full
consistent stack of dependencies but the solution is not bom and exists
since 10+ years in maven natively.


>
>
> Thomas
>
>
>
> On 19/03/2025 13:43, Romain Manni-Bucau wrote:
> > Can we step back a sec, what does bom bring that is not solved without?
> > Dependency resolution is perfectly handled with type=pom (without
> > scope=import), reusability with multiple scope is quite trivial with a
> > property for the version and potentially the whole gav.
> > At the end we can forbid (= stop supporting) bom in v>4.0.0 poms IMHO.
> >
> > Romain Manni-Bucau
> > @rmannibucau  | .NET Blog
> >  | Blog 
> | Old
> > Blog  | Github
> >  | LinkedIn
> >  | Book
> > <
> https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064
> >
> >
> >
> > Le mer. 19 mars 2025 à 11:51, Tamás Cservenák  a
> > écrit :
> >
> >> Howdy,
> >>
> >> some tooling already exists:
> >> gav-dm-tree:
> >> https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bf
> >> gav-dm-list
> >> <
> https://gist.github.com/cstamas/7e3f8d444a74d9a2f4f7d7114af156bfgav-dm-list
> >:
> >> https://gist.github.com/cstamas/419f4663744150b76f737cbd89fedf4f
> >> and the new "flatten bom" mojo.
> >>
> >> And my proposal is to "pre-digest" the BOM, not any BOM you consume,
> >> just those super-BOMs that have deep (import) hierarchy (look at
> >> dm-tree and dm-list outputs above).
> >> While I did flatten-BOM, I was also tinkering to do some "merge" or
> >> alike, but realized that:
> >> * simple tool is better than complex
> >> * flatten "solves" the problem for big BOMs (for example, using this
> >> tool for Junit BOM makes no sense)
> >> * the rest of how to "fit" flattened BOM becomes simpler, as now that
> >> they are flat, you DO have control.
> >> * generation of flat BOM should be consistent: for same BOM GAV the
> >> output should be SAME -- just keep it simple; if we add knobs like
> >> which version to select, user could easily shoot himself in the foot
> >>
> >> The goal of new mojo is to flatten input BOM and do it consistently:
> >> if you point it at same BOM, your output is same as before (sans
> >> possible coordinate change of the emitted BOM itself)
> >>
> >> T
> >>
> >> On Wed, Mar 19, 2025 at 9:16 AM Hervé Boutemy 
> wrote:
> >>>
> >>> FTR Jira issues
> >>> https://issues.apache.org/jira/browse/MNG-7906
> >>> https://issues.apache.org/jira/browse/MNG-7854
> >>> https://issues.apache.org/jira/browse/MPH-183
> >>> and all linked issues
> >>>
> >>> I don't know how this is r