Skip to content

Draft: add blog about maven artifact resolution - #384

Open
sebtiem wants to merge 2 commits into
mainfrom
blog-maven-artifacts
Open

Draft: add blog about maven artifact resolution#384
sebtiem wants to merge 2 commits into
mainfrom
blog-maven-artifacts

Conversation

@sebtiem

@sebtiem sebtiem commented Aug 11, 2026

Copy link
Copy Markdown
Collaborator

No description provided.

@netlify

netlify Bot commented Aug 11, 2026

Copy link
Copy Markdown

Deploy Preview for open-elements ready!

Name Link
🔨 Latest commit efb87b9
🔍 Latest deploy log https://app.netlify.com/projects/open-elements/deploys/6a7c1da700406f0008bdeca7
😎 Deploy Preview https://deploy-preview-384--open-elements.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.
Lighthouse
Lighthouse
1 paths audited
Performance: 68
Accessibility: 98
Best Practices: 92
SEO: 92
PWA: 60
View the detailed breakdown and full score reports

To edit notification comments on pull requests, go to your Netlify project configuration.


Ein Vergleich ist allerdings nur so gut wie sein Vergleichsmaßstab. Wenn eine der beteiligten Abhängigkeiten nicht aus einem öffentlichen Repository stammt, sondern aus einem `mvn install`, das vor drei Wochen auf demselben Rechner gelaufen ist, dann vergleicht man am Ende ein lokales Ergebnis mit einem anderen lokalen Ergebnis. Das Resultat sieht sauber aus, es sagt aber nichts über die öffentlich veröffentlichten Artefakte aus. Aus Supply-Chain-Sicht ist ein lokal installiertes Artefakt ein Eingang in den Build, der von niemandem geprüft wurde, weder durch eine Signatur noch durch eine Checksumme gegen ein Remote-Repository.

Genau diese Lücke wurde in MARTIFACT-58 beschrieben. Seine Beobachtung: `artifact:compare` vergleicht die Ausgabe des aktuellen Builds mit Inhalten aus dem lokalen Repository, und was sich dabei nicht leicht erkennen lässt, ist, ob dieser Inhalt aus einem früheren lokalen `mvn install` stammt oder aus einem Remote-Repository heruntergeladen wurde. Sein Vorschlag war, dass das Plugin diese Information selbst ermitteln und anzeigen könnte.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link zu MARTIFACT-58


## Warum die Herkunft ein Supply-Chain-Thema ist

Das Maven Artifact Plugin ist das Werkzeug, mit dem im Maven-Ökosystem Reproducible Builds nachgewiesen werden. Das Ziel `artifact:buildinfo` erzeugt eine Beschreibung des Build-Ergebnisses inklusive Checksummen, und `artifact:compare` vergleicht das Ergebnis des aktuellen Builds mit einer Referenz. Wenn beide übereinstimmen, ist gezeigt, dass die veröffentlichten Artefakte tatsächlich aus dem angegebenen Quellcode entstanden sein können.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link zu Maven Artifact Plugin

@@ -0,0 +1,88 @@
# Woher kommt dieses Artefakt eigentlich? Maven, das lokale Repository und die Datei `_remote.repositories`

Reproducible Builds beruhen auf einer einfachen Zusage: derselbe Quellcode, dieselbe Build-Umgebung, dasselbe Ergebnis, Byte für Byte. Wer diese Zusage überprüfen will, braucht eine verlässliche Referenz, und genau an dieser Stelle wird es interessant, denn die Referenz liegt bei Maven im lokalen Repository, also in einem Verzeichnis, dem man auf den ersten Blick nicht ansehen kann, woher sein Inhalt stammt.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.


## Das lokale Repository als gemischte Ablage

Die Maven-Dokumentation beschreibt das lokale Repository offen als gemischte Ablage, die zwei Aufgaben gleichzeitig erfüllt: Sie ist Cache für Artefakte, die von einem Remote-Repository geladen wurden, und sie ist Ablage für Artefakte, die lokal gebaut und installiert wurden. Beide landen im selben Layout, also unter demselben Pfad aus GroupId, ArtifactId und Version. Aus dem Pfad allein lässt sich die Herkunft folglich nicht ablesen.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Link zu Maven-Dokumentation


Die Resolver-API ist konsequent nach dem Muster Request und Result aufgebaut, und die verschiedenen Request-Typen entsprechen den verschiedenen Fragen, die man an ein Repository stellen kann.

`VersionRequest` und `VersionRangeRequest` klären Koordinaten, etwa die Auflösung eines Versionsbereichs oder die Übersetzung einer Snapshot-Version in eine konkrete Zeitstempelversion. Der `ArtifactDescriptorRequest` liest die Beschreibung eines Artefakts, also im Wesentlichen dessen POM inklusive direkter Abhängigkeiten und möglicher Relocations. Der `CollectRequest` baut daraus einen Abhängigkeitsgraphen auf und liefert im `CollectResult` einen Baum aus `DependencyNode`-Objekten, ohne dabei die eigentlichen Dateien herunterzuladen. Der `DependencyRequest` geht einen Schritt weiter und löst zusätzlich die Dateien des Graphen auf. Der `ArtifactRequest` schließlich fragt nach genau einem Artefakt und liefert ein `ArtifactResult` zurück. Daneben stehen `MetadataRequest` für Repository-Metadaten, `LocalArtifactRequest` als Frage direkt an das lokale Repository, sowie `InstallRequest` und `DeployRequest` für den Weg nach außen.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich glaube das ist deutlich zu detailliert für einen Blockpost und wird nicht benötigt. Das ist ja quasi schon Java Doc :D


Unterhalb von Maven arbeitet der Maven Artifact Resolver, das frühere Aether. Er kapselt alles, was mit Repositories zu tun hat, hinter dem Einstiegspunkt `RepositorySystem` und einer `RepositorySystemSession`, die die aktuelle Konfiguration des Builds trägt.

Für das lokale Repository ist der `LocalRepositoryManager` zuständig, kurz LRM. Der Resolver bringt zwei Implementierungen mit. Die Variante `simple` ist funktionsfähig, aber vor allem für Tests gedacht und nicht für den produktiven Einsatz empfohlen. Die Variante `enhanced` ist die zur Laufzeit verwendete, und sie ist genau dort erweitert, wo es für dieses Thema zählt: Sie merkt sich, aus welchem Repository ein gecachtes Artefakt aufgelöst wurde.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Die LRM finde ich komisch und ,musste mehrmals hochsollen um zu sehen was das noch einmal war. Ich frag mich ob die weggelassen werden soll.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants