Enforcer Plugin Custom Rules

Hallo zusammen,

nutze das Maven Enforcer Plugin um den Build brechen zu lassen falls zB. die flasche Maven Version oder Java Version eingesetzt wird.

Zusaetzlich bricht der Build wenn es Konvergenzen gibt (http://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html).

Was mir noch fehlt, waere eine Rule die den Build bricht wenn undeklarierte (also rein transitive) Dependencies direkt genutzt werden (http://maven.apache.org/plugins/maven-dependency-plugin/usage.html#The_dependency:analyze_mojo), habe dazu allerding keine fertige Rule oder ein Plugin gefunden.

Das Dependency Plugin wurde den Build auch brechen wenn deklarierte Dependencies nicht genutzt wuerden, allerdings ist dieser Report unzuverlaessig (reflection etc. verhindert die exakte Bestimmung ob eine Dependency genutzt wird oder nicht).

Hat jemand hier so eine Rule schon mal im Netz gefunden, oder muss ich emine eigene schreiben? :slight_smile:

Kenne leider keins, wäre allerdings auch daran interessiert und würde ggf. auch beim entwickeln/testen helfen.

Ich nutze ansonsten manchmal noch Enforcer Rules von https://github.com/ferstl/pedantic-pom-enforcers

Danke fuer das Angebot :slight_smile:
Muss erstmal eine Version implementieren, die hier im Betrieb laeuft, inkl. Company POM als Parent.
Deswegen kann ich die Sourcen nicht zu 100% hier abdrucken (einige Teile der POM muessen draussen bleiben, packet namen etc. pp.).

Es spricht IMHO aber nix dagegen hier “gereinigte” POM & Code Fragmente etc. zu posten um dann daraus ein “oeffentliches” Enforcer Plugin Rule zu schreiben.

Danke! Interessante Sammlung…

Ja, manche Rules sind in der Tat sehr pedantisch aber z.B. die PedanticDependencyConfigurationEnforcer finde ich sinnvoll.

Sorry @mvitz das ich mich erst so spaet wieder melde…

Habe mal reingesehen

This enforcer makes sure that dependency versions and exclusions are declared in the section.

In der Tat, das fehlte mir noch :slight_smile:

Hab emal an der Custom Enforcer Rule und an einem PLugin weitergeschraubt, will noch ein bisschen aufraeumen bevor ich das hier dann poste.
Sowohl Plugin als auch Enforcer Rule sind moeglich, allerdings muss man bei der Enfocer Rule aufpassen dass es auhc wirklich erst in der testCompile Phase aufgerufen wird, sonst stimmt das Ergebniss nicht (Dependencies sind unvollstaendig und daher wird nix UsedUndeclared gefunden).

Genutzt wird uebrigens ProjectDependencyAnalysis aus maven-depdency-analyzer.
Sieht dann in etwa so aus:

            final Set<Artifact> usedUndeclaredArtifacts = analysis.getUsedUndeclaredArtifacts();```

Kein Problem @maki , hatte auch viel zu tun die Tage :wink:
Gibt es dann ggf. auch noch die Möglichkeit relativ einfach an Dependencies zu gelangen, die zwar Declared aber nicht Used sind?

Hi,

Also Du meinst, wenn eine Dependency nicht im dependencyManagement Block deklariert ist? Oder wie meinst Du das genau ?

[QUOTE=maki;28234]Das Dependency Plugin wurde den Build auch brechen wenn deklarierte Dependencies nicht genutzt wuerden, allerdings ist dieser Report unzuverlaessig (reflection etc. verhindert die exakte Bestimmung ob eine Dependency genutzt wird oder nicht).[/quote]Genau da liegt der Hase im Pfeffer…

Ich weiß nicht, ob da eine Rule reicht?..

Gruß
Karl-Heinz Marbaise

[QUOTE=kama]Also Du meinst, wenn eine Dependency nicht im dependencyManagement Block deklariert ist?
[/QUOTE]
Nein, ich meinte wenn man eine transitie Dependency direkt nutzt, zB. nur die commons-beanutils als Dependency in der POM angeben und dann im Code commons-logging direkt nutzen .
commons-logging ist eine transitive Dependency von commons-beanutils.
Damit stehen die genutzten Dependencies nicht in der POM…

Das Dependency Plugin bietet das Analyze Mojo an: mvn dependency:analyze
Es geht um die “undeclared used artifacts”.

Genau da liegt der Hase im Pfeffer…

Ja, verhindert das man der “declared but unsed” Ausgabe trauen kann.

Ich weiß nicht, ob da eine Rule reicht?..

Bin mittlerweile der Meinung dass eine eigenes Plugin besser waere, einmal weil das Enforcer Plugin per default in der validate Phase laeuft, also wenn der Classpath noch nicht komplett ist vor dem kompilieren.
Dann kommt dazu dass durch die Umstellung auf Aether in Version 1.3 des Enforcer Plugins um mit Maven 3.1 zu funktionieren die Sache deutlich komplizierter geworden ist IMHO, in der Enforcer Version 1.3.1 ist das nochmal schwieriger geworden, weil man das requiresDependencyCollection = ResolutionScope.TEST Attribut vom Enforce Mojo entfernt hat.

Ein Plugin zu schreiben welches einfach nur den ProjectAnalyzer vom Dependency Plugin nutzt ist dagegen viel einfacher (man kann DI nuzten, das geht in einer zB. Enforcer Rule nicht) und wahrscheinlich auch bestaendiger, halte es fuer sehr wahrscheinlich dass das Dependency Plugin noch weiter gepflegt wird :wink: