Il plugin maven-dependency usa qualche altro tipo di risoluzione degli artefatti rispetto al resto di Maven?

Question

Se utilizzo il plugin per il plugin maven-dependency, non posso usare un intervallo di versione. Sembra anche che la versione di un artefatto definito non venga aggiornata anche se una versione più recente è nel repository remoto.

Perché è così?

Utilizza il plug-in maven-dependency qualche altro meccanismo rispetto al resto di maven per risolvere le dipendenze? E se questo è il caso, perché?

Ecco un esempio:

ho creato un progetto org.example: org.example.simple.project1: Vaso e metterlo nel repository utilizzando le versioni 1.0.0 -snapshot, 1.0.0, 1.0.1 e1.1.0-SNAPSHOT

ora ho configurato il plugin dipendenza nel seguente modo:

<plugin> 
    <groupId>org.apache.maven.plugins</groupId> 
    <artifactId>maven-dependency-plugin</artifactId> 
    <executions> 
     <execution> 
      <id>unpack-stuff<id> 
      <phase>initialize</phase> 
      <goals> 
       <goal>unpack</goal> 
      </goals> 
      <configuration> 
       <artifactItems> 
        <artifactItem> 
         <groupId>org.example</groupId> 
         <artifactId>org.example.simple.project1.</artifactId> 
         <version>[1.0,1.1)</version> 
         <type>jar</type> 
         <overWrite>true</overWrite> 
         <outputDirectory>target/stuff</outputDirectory> 
         <includes>**/*.*</includes> 
        </artifactItem> 
       </artifactItems> 
      </configuration> 
     </execution> 
    </executions> 
</plugin> 

Se la risoluzione delle dipendenze è la stessa delle altre dipendenze, la risoluzione della versione (almeno a mio avviso) è 1.0.1.

Invece ottengo la seguente eccezione:

[ERROR] FATAL ERROR 
[INFO] ------------------------------------------------------------------------ 
[INFO] version was null for org.example:org.example.simple.project1. 
[INFO] ------------------------------------------------------------------------ 
[INFO] Trace 
java.lang.NullPointerException: version was null for org.example:org.example.simple.project1. 
at org.apache.maven.artifact.DefaultArtifact.getBaseVersion(DefaultArtifact.java:362) 
at org.apache.maven.artifact.repository.layout.DefaultRepositoryLayout.pathOf(DefaultRepositoryLayout.java:47) 
at org.apache.maven.artifact.repository.DefaultArtifactRepository.pathOf(DefaultArtifactRepository.java:110) 
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:125) 
at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:74) 
at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getArtifact(AbstractFromConfigurationMojo.java:242) 
at org.apache.maven.plugin.dependency.fromConfiguration.AbstractFromConfigurationMojo.getProcessedArtifactItems(AbstractFromConfigurationMojo.java:143) 
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.getProcessedArtifactItems(UnpackMojo.java:138) 
at org.apache.maven.plugin.dependency.fromConfiguration.UnpackMojo.execute(UnpackMojo.java:88) 
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292) 
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) 
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) 
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) 
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
at java.lang.reflect.Method.invoke(Method.java:597) 
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) 
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) 
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) 
at org.codehaus.classworlds.Launcher.main(Launcher.java:375) 
[INFO] ------------------------------------------------------------------------ 
[INFO] Total time: 4 seconds 
[INFO] Finished at: Mon Aug 03 17:21:41 CEST 2009 
[INFO] Final Memory: 13M/133M 
[INFO] ------------------------------------------------------------------------ 

Answer 1

Ok ecco la risposta reale (ho scritto il plugin dipendenza):

Lo scompattare e copiare obiettivi devono replicare parte del codice risoluzione nucleo. Sfortunatamente quel codice di risoluzione non era realmente in una forma utilizzabile api-saggio. Per questo motivo, questi obiettivi non gestiscono gli intervalli di versione e non risolvono gli artefatti direttamente dal reattore (io sinceramente non li ho mai implementati perché ha rotto troppi casi d'uso esistenti, sì, il codice di risoluzione era così male)

Un approccio molto migliore è utilizzare le forme delle dipendenze xxx di questi obiettivi. Questi obiettivi chiedono a Maven di fare la risoluzione prima di essere invocati e quindi è compatibile al 100%. Puoi utilizzare i filtri come il filtro groupId e artifactId per ottenere in modo efficace l'elenco degli artefatti desiderati e il risultato finale sarà lo stesso.

La copia e il disimballaggio sono decisamente più flessibili e sono stati pensati per un caso di utilizzo molto più semplice che avevo in quel momento. Sapendo quello che so ora, probabilmente l'avrei implementato più come le formule delle dipendenze xxx per cominciare.

Tutto ciò detto, in Maven 3, il codice di risoluzione è finalmente completamente disaccoppiato ... il plugin di dipendenza guida la maggior parte dei casi d'uso necessari per questo. Inizierò a lavorare su una nuova versione del plug-in per sfruttare al massimo questo ... e mentre richiederà maven 3, funzionerà al 100% con tutti gli obiettivi.

Answer 2

Il plugin di dipendenza utilizza lo stesso meccanismo di risoluzione come tutto il resto. È possibile che i repository non stiano aggiornando i metadati perché è impostato su mai o settimanale o qualcosa del genere. Puoi forzare Maven ad aggiornare tutti i metadati del repository remoto eseguendo con -U.

Anche il plug-in delle dipendenze non sovrascrive le dipendenze scaricate per impostazione predefinita se sono già presenti nella destinazione. È possibile eseguire una pulizia o configurare l'obiettivo per forzare le sovrascritture. Esistono tre parametri che è possibile impostare su true: overWriteIfNewer, overWriteReleases e overWriteSnapshots. Vedi the documentation per maggiori dettagli.

Modifica: in base alla domanda aggiornata, il problema è che si sta utilizzando un intervallo di dipendenza. Gli intervalli vanno bene finché c'è qualcosa per risolvere la versione (ad esempio la versione definita nel progetto padre o nella sezione delle dipendenze). Se si modifica l'intervallo su una versione esatta o si utilizza uno dei codici LATEST or RELEASE keywords, Maven sarà in grado di risolvere il numero di versione (pur essendo consapevole che tali parole chiave comportano i propri rischi.

Si consiglia di definire una sezione di gestione delle dipendenze nel tuo genitore con le versioni che usi, i tuoi progetti possono ereditare quelle versioni. Ho risposto ad un'altra domanda a riguardo recentemente, posterò un link se lo trovo

Answer 3

Il problema con gli intervalli di dipendenza è che non hai specificato una delle versioni che hai usato Se hai specificato l'intervallo come [1.0.0.1.1.0-SNAPSHOT), allora potrebbe fare come ti aspetti. Non puoi supporre che 1.0 e 1.1 si risolvano in 1.0. * E 1.1. * Che è ciò che sembra implicare.

Answer 4

A partire dalla versione 3.0.0 il plug-in maven-dependency ora supporta questa funzionalità. Ringraziamenti e ringraziamenti a Brian_Fox