Maven-Plugin, um die Verwendung bestimmter Pakete zu beschränken

8

Ich arbeite in einem Team von ungefähr 40 Entwicklern, und ich möchte nicht, dass irgendein Entwickler eine bestimmte API (java.sun.Base64, um genau zu sein) verwendet, die von irgendeinem der Entwickler verwendet werden kann, und sie stattdessen dazu bringen soll, Alternativen zu verwenden die Sonne API als sein Eigentum.

Gibt es irgendwelche Plugins für maven, durch die die eingeschränkten Pakete in der pom.xml angegeben werden, bricht der Build ab, wenn eines dieser Pakete irgendwo im Code verwendet wird?

Oder gibt es einen anmutigen Weg, dies zu tun?

Danke

    
Neeraj 19.09.2011, 07:39
quelle

8 Antworten

8

Sie möchten eine Architekturregel für Ihr Projekt definieren, die am besten durch Quellcodeanalyse durchgesetzt wird.

Sonar kann nun angeben solche Regeln und zeigt Verstöße gegen das Qualitäts-Dashboard des Projekts an. Wenn Sie möchten, dass der Build unterbrochen wird, können Sie dies zusätzlich tun, indem Sie Sonars Build-Breaker Plug-in aktivieren .

Sonar ist wirklich einfach zu installieren und integriert sich in Ihren Maven-Build-Prozess ohne Änderung an Ihrem POM.

    
Mark O'Connor 19.09.2011, 18:53
quelle
6

Hier ist ein Plug-in, das ich für ähnliche Zwecke geschrieben habe.

Details können hier gesehen werden: Ссылка

Schränken Sie den gesamten Zugriff von com.ya * auf java.util.regex. *

ein %Vor%

Schränken Sie den gesamten Zugriff von com.ya * (außer com.yamanyar.core. ) auf java.util.regex. ,

ein %Vor%

Schränken Sie den gesamten Zugriff von com.ya * (außer com.yamanyar.core. ) und com.abc.Test auf java.util.regex.

ein

<restriction>com.ya*,com.abc.Test,!com.yamanyar.core.* to java.util.regex.*</restriction>

Beschränken Sie den gesamten Zugriff von com.ya * (außer com.yamanyar.core. ) und com.abc.Test auf java.util.regex. (außer java.util.regex.Matcher) <restriction>com.ya*,com.abc.Test,!com.yamanyar.core.* to java.util.regex.*,!java.util.regex.Matcher</restriction>

Beschränken Sie den gesamten Zugriff von com.ya * (außer com.yamanyar.core. ) und com.abc.Test auf java.util.regex. (außer java.util.regex.Matcher) ; und beschränken Sie auch com.ya * (außer com.yamanyar.core. ) auf java.io.PrintStre .print * ()

%Vor%     
Kaan Yy 06.11.2013 09:33
quelle
6

Sehen Sie dies :

%Vor%

Dabei ist die Regel so definiert, dass der Import von java.lang.System

nicht erlaubt ist %Vor%     
Maciej A. Bednarz 26.02.2013 08:06
quelle
1

Mir ist kein Maven-Plugin dafür bekannt, aber ich könnte mir vorstellen, dass Sie mit Aspekten ähnlich machen könnten (und deshalb das Maven / Aspectj-Plugin verwenden). Aspectj hat das Fehler deklarieren Konstrukt, das nützlich sein könnte. Dies kann zu einem Fehler führen, wenn ein Pointcut mit verbotenen Klassen erkannt wird.

Auch Ссылка

Eine Einschränkung dieses Ansatzes ist, dass es sich um eine statische Analyse handelt und somit keine "cleveren" Aufrufe Ihrer Klassen- / Paket-Blacklist auffliegen können.

    
Paul Grime 19.09.2011 09:47
quelle
1

Sie können prüfen, welche Klassen in Ihrem Klassenladeprogramm geladen sind, und einen Fehler melden, wenn Sie etwas von java.sun.Base64 finden.

Dies scheint zu funktionieren: Ссылка

>     
iuiz 19.09.2011 09:52
quelle
1

Hier ist ein Konzeptcode für PMD / Maven PMD plugin . (Die eingeschränkten Klassen sind im Konstruktor fest codiert, aber es ist möglich, sie über Eigenschaften konfigurierbar zu machen.)

%Vor%

Erstellen Sie ein neues Maven-Projekt dafür und verwenden Sie dieses Projekt als eine Abhängigkeit des PMD-Plugins in Ihrem Projekt:

%Vor%

Außerdem benötigt das PMD-Plugin eine korrekte Regelsatz-XML-Datei für die Regelklasse. Es gibt ein Beispiel auf der PMD-Website: Ссылка . Platziere es einfach im src / main / resources-Ordner in deinem PackageRestrictionRule-Projekt und das Plugin findet es im Klassenpfad.

    
palacsint 20.09.2011 22:14
quelle
0

Dieser Vorschlag ist das Gegenteil von "anmutig"; Es ist ein totaler Kluge: Es könnte einfach genug sein, etwas zu schreiben, um in die Prozess-Quellen-Phase des Builds zu kommen ... Sie könnten (zum Beispiel) alle Fälle von "sun.Base64" durch einen (ungültigen Java) Text ersetzen das Problem anzeigend. Dies würde dazu führen, dass der Build mindestens fehlschlägt.

    
Zac Thompson 19.09.2011 22:42
quelle
0

Eine einfache Option kann darin bestehen, ein "Eltern" -Pom zu verwenden, um alle Ihre Drittanbieter-JAR-Dateien mit Versionen im Abschnitt "Dependency Management" zu definieren und sie in untergeordneten Poms zu verwenden. Auch wenn dieses Modell die Verwendung eines bestimmten Krugs nicht in Abrede stellt, können der PM oder der Architekt die Abhängigkeiten auf einfache Weise verwalten. Sobald dies erledigt ist, können wir den Entwicklern einfach sagen, dass sie nur die Abhängigkeiten verwenden sollen, die im Eltern-Pom verwendet werden.

    
skn 24.08.2016 09:04
quelle

Tags und Links