Qual è la differenza in maven tra dipendenze e tag plugin in pom xml?

Sono nuovo allo strumento Maven, ho realizzato un progetto con Spring e Hibernate e sono configurati in pom.xml come plugin, ma JUnit è etichettato come dipendenza. La mia domanda è: qual è la logica dietro uno come plugin e uno come dipendenza?

Sia i plugin che le dipendenze sono file Jar.

Ma la differenza tra loro è che la maggior parte del lavoro in Maven viene svolto utilizzando i plugin; mentre la dipendenza è solo un file Jar che verrà aggiunto al classpath durante l'esecuzione delle attività.

Ad esempio, si utilizza un plug-in del compilatore per compilare i file java. Non è possibile utilizzare il plug-in del compilatore come dipendenza poiché ciò aggiungerà solo il plug-in al classpath e non attiverà alcuna compilazione. I file Jar da aggiungere al classpath durante la compilazione del file verranno specificati come dipendenza.

Lo stesso vale per il tuo scenario. Devi usare spring-plugin per eseguire alcuni eseguibili spring [Non sono sicuro di cosa siano usati i plugin spring. Sto solo ipotizzando qui]. Ma hai bisogno di dipendenze per eseguire quegli eseguibili. E Junit è etichettato come dipendenza poiché viene utilizzato dal plugin infallibile per eseguire test unitari.

Quindi, possiamo dire, il plugin è un file Jar che esegue l'attività e la dipendenza è un Jar che fornisce i file di classe per eseguire l'attività.

Spero che risponda alla tua domanda!

Lo stesso Maven può essere descritto come un robot da cucina che ha molte unità diverse che possono essere utilizzate per svolgere compiti diversi. Queste unità sono chiamate plugin. Ad esempio, per compilare il tuo progetto usa Maven maven-compiler-plugin, per eseguire test maven-surefire-plugine così via.

La dipendenza in termini di maven è un pacchetto di classi da cui dipende il tuo progetto. Può essere jar, war ecc. Ad esempio, se vuoi essere in grado di scrivere test JUnit, dovrai usare annotazioni e classi JUnit quindi devi dichiarare che il tuo progetto dipende da JUnit.

Plugin e dipendenze sono cose molto diverse e sono complementari.

Cosa sono i plugin?

I plugin eseguono attività per una build Maven. Questi non sono inclusi nell'applicazione.

Questi sono il cuore di Maven.
Qualsiasi attività eseguita da Maven viene eseguita dai plugin .
Esistono due categorie di plugin: i builde i reportingplugin :

• I plug-in di build verranno eseguiti durante la build e dovrebbero essere configurati <build/>nell'elemento dal POM.
• I plugin di report verranno eseguiti durante la generazione del sito e dovrebbero essere configurati nell'elemento <reporting/> dal POM.

Secondo l'obiettivo Maven specificato nella riga di comando (per esempio mvn clean, mvn clean packageo mvn site), una specifica ai cicli di vita sarà utilizzato e verrà eseguito uno specifico insieme di plugin obiettivi.
Ci sono tre built-in cicli di vita di build: default, cleane site. Il defaultciclo di vita gestisce la distribuzione del progetto, il cleanciclo di vita gestisce la pulizia del progetto, mentre il siteciclo di vita gestisce la creazione della documentazione del sito del progetto.

L'obiettivo di un plugin può essere legato a una fase specifica di uno specifico stile di vita.
Ad esempio le maven-compiler-pluginlega per impostazione predefinita l' compileobiettivo alla fase del ciclo di vita: compile.
La maggior parte dei plugin maven (sia plugin core che plugin di terze parti) preferisce le convenzioni alla configurazione. Quindi questi generalmente vincolano l'obiettivo di un plug-in a una fase specifica per semplificarne l'utilizzo.

Questo è più ordinato e meno soggetto a errori:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
</plugin>

di:

<plugin>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>3.7.0</version>
  <executions>
    <execution>
        <phase>compile</phase>
        <goals>
            <goal>compile</goal>
        </goals>
    </execution>
  </executions>
</plugin>

Quali sono le dipendenze?

Le dipendenze sono artefatti / componenti Maven richiesti nel classpath durante la compilazione Maven.
Questi possono essere inseriti nell'applicazione ma non necessariamente (vedi scopesotto).

La maggior parte delle dipendenze sono jar ma questi possono anche essere altri tipi di archivi: war, ear, test-jar, ejb-client ... o ancora POM o BOM.
In un pom.xml, le dipendenze possono essere specificate in più punti: la <build><dependencies>parte, la dependencies managementparte o ancora in una plugindichiarazione ! In effetti, alcuni plugin potrebbero dover avere alcune dipendenze nel classpath durante la loro esecuzione. Non è comune, ma può accadere.
Ecco un esempio dalla documentazione che lo mostra plugine dependencypotrebbe funzionare insieme:

Ad esempio, la versione 1.2 del plug-in Maven Antrun utilizza la versione 1.6.5 di Ant, se si desidera utilizzare l'ultima versione di Ant quando si esegue questo plug-in, è necessario aggiungere un <dependencies>elemento come il seguente:

<project>
  ...
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-antrun-plugin</artifactId>
        <version>1.2</version>
        ...
        <dependencies>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant</artifactId>
            <version>1.7.1</version>
          </dependency>
          <dependency>
            <groupId>org.apache.ant</groupId>
            <artifactId>ant-launcher</artifactId>
            <version>1.7.1</version>
          </dependency>
         </dependencies>
      </plugin>
    </plugins>
  </build>
  ...
</project>

In Maven, le dipendenze si fa riferimento in un formato specifico:
groupId:artifactId:packaging:classifier:version.
Il classificatore (che è opzionale) e la confezione ( JARper impostazione predefinita) non sono comunemente specificati. Così il formato comune nella dependencydichiarazione è piuttosto: groupId:artifactId:version.
Ecco un esempio di dipendenza dichiarata nella <build><dependencies>parte:

<build>
   <dependencies>
      <dependency>
         <groupId>org.hibernate</groupId>
         <artifactId>hibernate-core</artifactId>
         <version>5.2.14.Final</version>
      </dependency>
   <dependencies>
</build>

Contrariamente a un plugin, una dipendenza ha un ambito.
L'ambito predefinito è compile. Questo è l'ambito più comunemente necessario (di nuovo convenzione sulla configurazione).
L' compileambito significa che la dipendenza è disponibile in tutti i percorsi di classe di un progetto.

L'ambito definisce in quali percorsi di classe deve essere aggiunta la dipendenza. Ad esempio, ne abbiamo bisogno in fase di compilazione e runtime o solo per la compilazione e l'esecuzione dei test?

Ad esempio, abbiamo precedentemente definito Hibernate come una compiledipendenza in quanto ne abbiamo bisogno ovunque: compilazione dei sorgenti, compilazione dei test, runtime e così via ...
Ma non vogliamo che le librerie di test possano essere impacchettate nell'applicazione o referenziate nel codice sorgente . Quindi specifichiamo l' testambito per loro:

<build>
   <dependencies>
     <dependency>
        <groupId>org.junit.jupiter</groupId>
        <artifactId>junit-jupiter-engine</artifactId>
        <version>5.1.0</version>
        <scope>test</scope>
     </dependency>
   <dependencies>
</build>

Se provieni da uno sfondo front-end come me e hai familiarità con Grunt e npm, pensalo in questo modo:

In primo luogo si dovrebbe eseguire, ad esempio, npm install grunt-contrib-copy --save-dev. Questo è come quello di Maven <dependency></dependency>. Scarica i file necessari per eseguire un'attività di compilazione.

Quindi configurerai l'attività in Gruntfile.js

copy: {
  main: {
    src: 'src/*',
    dest: 'dest/',
  },
}

Questo è come quello di Maven <plugin>/<plugin>. Stai dicendo allo strumento di compilazione cosa fare con il codice scaricato da npm / <dependency></dependency>.

Ovviamente questa non è un'analogia esatta, ma abbastanza vicina da aiutarti a capirlo.

I plug-in vengono utilizzati per aggiungere funzionalità a Mavense stesso (come l'aggiunta di eclipsesupporto o SpringBootsupporto a Mavenecc.). Le dipendenze sono necessarie al codice sorgente per superare qualsiasi fase Maven ( compileo testper esempio). In caso di JUnitpoiché il codice di test è fondamentalmente parte della tua base di codice e chiami JUnitcomandi specifici all'interno delle suite di test e quei comandi non sono forniti da Java SDKquindi JUnitdevono essere presenti al momento Mavenè in fase di test e questo viene gestito menzionandolo JUnitcome dipendenza nel tuo pom.xmlfile.

Maven al suo centro è un framework di esecuzione di plugin, secondo la definizione compatta formale e standard. Per renderlo più chiaro, i comandi che usi come maven-install/clean/compile/build etcper creare / eseguire jars, che a volte eseguiamo anche manualmente. Quindi, le cose che vuoi eseguire (o configurare o eseguire) le metti fondamentalmente nel tag di dipendenza di mavens pom e la risposta in modo che chi eseguirà queste dipendenze (richiesto per la configurazione dell'ambiente) saranno i plugin.

        javac (compiler) dependency.java (dependency) 

Risposta in una riga: comprensione di base

Plugin è uno strumento che usi durante l'esecuzione della tua build di Maven

Dipendenza indica il tipo di qualsiasi libreria che utilizzerai nel tuo codice

Un plugin è un'estensione di Maven, qualcosa usato per produrre il tuo artefatto (maven-jar-plugin per un esempio, è usato, indovina, per creare un jar dalle tue classi e risorse compilate).

Una dipendenza è una libreria necessaria per l'applicazione che si sta creando, in fase di compilazione e / o test e / o runtime.