Plugin Maven per limitare l'utilizzo di pacchetti specifici

Question

Lavoro in un team di circa 40 sviluppatori e non voglio che nessuno sviluppatore utilizzi una specifica API (java.sun.Base64 per essere precisi) per essere utilizzata da qualsiasi gli sviluppatori e piuttosto li fanno usare alternative alla Sun API come sua proprietà.

Ci sono dei plugin per Maven, con i quali, specificando i pacchetti limitati nel pom.xml, la compilazione si interromperà se uno qualsiasi di questi pacchetti viene utilizzato da qualche parte nel codice ??

O c'è un modo più aggraziato per farlo ??

Grazie

Answer 1

si vuole definire una regola architettonica per il progetto, che è meglio applicata con l'analisi del codice sorgente.

Sonar ora ha la possibilità di specificare such rules e visualizzare le violazioni sul dashboard della qualità del progetto. Se si desidera interrompere la compilazione, è possibile eseguire anche il plug-in Build breaker di Sonar.

Sonar è davvero facile da configurare e si integra nel processo di creazione Maven con zero modifiche al POM.

Answer 2

io non sono a conoscenza di un plugin Maven per fare questo, ma immagino che si possa fare con aspetti simile (e quindi usare il plugin Maven/AspectJ). Aspectj ha il costrutto declare error che può essere utile. Questo può generare un errore se rileva un collegamento di punti che utilizza le classi proibite.

anche http://www.eclipse.org/aspectj/doc/released/progguide/semantics-declare.html#warnings-and-errors

Un limite di questo approccio è che è un analisi statica e quindi non sarà in grado di catturare qualsiasi invocazioni 'intelligente' della vostra classe/pacchetto di black-list.

Answer 3

È possibile verificare quali classi vengono caricate nel caricatore di classi e generare un errore se si trova qualcosa da java.sun.Base64.

Questo sembra funzionare: http://www.javaworld.com/javaworld/javaqa/2003-07/02-qa-0725-classsrc2.html

Answer 4

Questo suggerimento è l'opposto di "grazioso"; è un kluge totale: potrebbe essere abbastanza semplice scrivere qualcosa da inserire nella fase process-sources della build ... potresti (per esempio) sostituire qualsiasi caso di "sun.Base64" con un testo (Java non valido) indicando il problema Ciò farebbe sì che la compilazione fallisca almeno.

Answer 5

Di seguito è riportato un codice di regola proof of concept per PMD/Maven PMD plugin. (Le classi ristrette sono hardcoded nel costruttore, ma è possibile farlo configurabile tramite le proprietà.)

import java.util.Collections; 
import java.util.LinkedList; 
import java.util.List; 

import net.sourceforge.pmd.AbstractJavaRule; 
import net.sourceforge.pmd.ast.ASTClassOrInterfaceType; 
import net.sourceforge.pmd.ast.ASTName; 
import net.sourceforge.pmd.ast.SimpleJavaNode; 

public class PackageRestrictionRule extends AbstractJavaRule { 

    private final List<String> disallowedPackages; 

    public PackageRestrictionRule() { 
     final List<String> disallowedPackages = new LinkedList<String>(); 
     disallowedPackages.add("org.apache."); 
     this.disallowedPackages = Collections 
       .unmodifiableList(disallowedPackages); 
    } 

    @Override 
    public Object visit(final ASTClassOrInterfaceType node, 
      final Object data) { 
     checkPackage(node, data); 
     return super.visit(node, data); 
    } 

    @Override 
    public Object visit(final ASTName node, final Object data) { 
     checkPackage(node, data); 
     return super.visit(node, data); 
    } 

    private void checkPackage(final SimpleJavaNode node, 
      final Object data) { 
     final String image = node.getImage(); 
     if (isDisallowedPackage(image)) { 
      addViolationWithMessage(data, node, 
        "Disallowed class or package: " + image); 
     } 
    } 

    private boolean isDisallowedPackage(final String packageName) { 
     for (final String disallowedPackageName : disallowedPackages) { 
      if (packageName.startsWith(disallowedPackageName)) { 
       return true; 
      } 
     } 
     return false; 
    } 
} 

Creare un nuovo progetto Maven per esso, e utilizzare questo progetto come una dipendenza del plugin PMD in il tuo progetto:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-pmd-plugin</artifactId> 
    <version>2.5</version> 
    <configuration> 
     <targetJdk>1.6</targetJdk> 
     <rulesets> 
      <ruleset>packagerestrictionrule.xml</ruleset> 
     </rulesets> 
    </configuration> 
    <dependencies> 
     <dependency> 
      <groupId>...</groupId> 
      <artifactId>PackageRestrictionRule</artifactId> 
      <version>0.0.1-SNAPSHOT</version> 
     </dependency> 
    </dependencies> 
</plugin> 

Inoltre, il plugin PMD necessita di un file XML ruleset appropriato per la classe rule. C'è un esempio sul sito Web PMD: http://pmd.sourceforge.net/howtowritearule.html. Basta posizionarlo nella cartella src/main/resources nel tuo progetto PackageRestrictionRule e il plugin lo troverà sul classpath.

Answer 6

Guardate this:

<plugin> 
     <groupId>org.codehaus.mojo</groupId> 
     <artifactId>macker-maven-plugin</artifactId> 
     <version>1.0.0-SNAPSHOT</version> 
     <executions> 
      <execution> 
      <phase>compile</phase> 
      <goals> 
       <goal>macker</goal> 
      </goals> 
      </execution> 
     </executions>  
     </plugin> 

in cui si definisce regola di non permettere l'importazione di java.lang.System

<?xml version="1.0"?> 
<macker>  
    <ruleset name="Testing rules"> 
     <pattern name="mypackage" class="org.codehaus.mojo.**" /> 
     <access-rule> 
      <message>System out is bad. Use logging instead.</message> 
      <deny> 
       <to> 
        <include class="java.lang.System" /> 
       </to> 
      </deny> 
      <!--allow> 
       <from pattern="blah" /> 
      </allow--> 
     </access-rule> 
    </ruleset> 
</macker> 

Answer 7

Ecco plug-in che ho scritto per scopi simili.

dettagli può essere visto qui: https://github.com/yamanyar/restrict-maven-plugin/wiki

Limita tutti gli accessi da com.ya * a * java.util.regex

<restriction>com.ya* to java.util.regex.*</restriction> 

Limita tutti gli accessi da com.ya * (ad eccezione COM.. yamanyar.core ) a java.util.regex.,

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

Limita tutti gli accessi da com.ya * (tranne com.yamanyar.core. ) e com.abc.Test a java.util.regex.

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

Limita tutti gli accessi da com.ya * (tranne com.yamanyar.core. ) e com.abc.Test a java.util.regex. (tranne java.util.regex.Matcher) <restriction>com.ya*,com.abc.Test,!com.yamanyar.core.* to java.util.regex.*,!java.util.regex.Matcher</restriction>

Limita tutti gli accessi da com.ya * (tranne com.yamanyar.core. ) e com.abc.Test a java.util.regex. (tranne java.util.regex.Matcher); e inoltre limitare com.ya * (tranne com.yamanyar.core. ) per java.io.PrintStre .print *()

<restriction>com.ya*,com.abc.Test,!com.yamanyar.core.* to java.util.regex.*,!java.util.regex.Matcher</restriction> 
<restriction>com.ya*,!com.yamanyar.core* to java.io.PrintStre*.print*()</restriction> 

Answer 8

Una possibilità semplice può essere quella di utilizzare un 'genitore' Pom per definire tutti i tuoi vasi di terze parti con le versioni nella sezione "Gestione delle dipendenze" e li usi nei poms dei bambini. Anche se questo modello non nega l'utilizzo di un particolare jar, il PM o l'architetto avranno un modo semplice per gestire le dipendenze. Una volta fatto, possiamo semplicemente dire agli sviluppatori di usare solo le dipendenze usate nel genitore principale.