[Will-thom]

Thanks for the clarification.

I retargeted the change to maven-3.10.x and updated the diagram to reflect the current structure:

• removed maven-shared-utils from the diagram
• added the maven-jline module
• represented JLine as the external dependency used through maven-jline
• updated the .odg source and synchronized maven-deps.svg

Please let me know if this matches the expected layout.

[olamy]

we should probably stop pushing binaries files.
with the coming support of mermaid of mermaid this could help?

[slawekjaranowski]

It is difficult to verify content of binary file ....

[gnodet]

we should probably stop pushing binaries files. with the coming support of mermaid of mermaid this could help?

The one for Maven 4 is auto-generated.

[olamy]

we should probably stop pushing binaries files. with the coming support of mermaid of mermaid this could help?

The one for Maven 4 is auto-generated.

the .odg?

I would even if generated we could avoid store binary files. and .svg or mermaid are rendering well

[gnodet]

I extracted and inspected the ODG file (it's a ZIP of XML files). It looks clean:

• no embedded scripts or macros (the <office:scripts> element is empty)
• all hyperlinks point to expected project sites (apache.org, eclipse.org, github.com, jline.org, slf4j.org) and relative file:///maven-* module references
• text labels match the expected Maven module names, including the new maven-jline and jline
• no embedded binaries besides the standard Thumbnails/thumbnail.png preview

That said, Maven 4 already generates this diagram at build time, so the binary source issue is solved there. And since the Maven 3 dependency structure is unlikely to change often at this point, it's probably not worth converting to a different format just for this branch.

Claude Code on behalf of Guillaume Nodet

[gnodet]

we should probably stop pushing binaries files. with the coming support of mermaid of mermaid this could help?

The one for Maven 4 is auto-generated.

the .odg?

I would even if generated we could avoid store binary files. and .svg or mermaid are rendering well

The diagram is generated at build time in Maven 4, so there's no ODG anymore.

[github-actions]

@gnodet Please assign appropriate label to PR according to the type of change.

[Will-thom]

we should probably stop pushing binaries files. with the coming support of mermaid of mermaid this could help?

The one for Maven 4 is auto-generated.

the .odg?
I would even if generated we could avoid store binary files. and .svg or mermaid are rendering well

The diagram is generated at build time in Maven 4, so there's no ODG anymore.

Hi guys, I´m thinking...

...rather than discussing whether ODG, SVG or Mermaid should be stored, perhaps the more important question is what should be the canonical source of the dependency graph. If the graph can be derived from the Maven reactor structure, a textual source (Mermaid/DOT) or fully generated artifact would avoid drift, simplify reviews and eliminate binary artifacts entirely.

[gnodet]

we should probably stop pushing binaries files. with the coming support of mermaid of mermaid this could help?

The one for Maven 4 is auto-generated.

the .odg?
I would even if generated we could avoid store binary files. and .svg or mermaid are rendering well

The diagram is generated at build time in Maven 4, so there's no ODG anymore.

Hi guys, I´m thinking...

...rather than discussing whether ODG, SVG or Mermaid should be stored, perhaps the more important question is what should be the canonical source of the dependency graph. If the graph can be derived from the Maven reactor structure, a textual source (Mermaid/DOT) or fully generated artifact would avoid drift, simplify reviews and eliminate binary artifacts entirely.

Yes, that's what is done in Maven 4, maybe I wasn't clear enough.
See https://github.com/apache/maven/blob/master/src/graph/ReactorGraph.java and https://github.com/apache/maven/blob/master/pom.xml#L970-L992