Qual è la differenza tra dipendenza di tipo "pom" con ambito "import" e senza "import"?

112

A partire da Maven 2.0.9 è possibile includere

<type>pom</type>
<scope>import</scope>

nella <dependencyManagement>sezione.

A quanto ho capito, verrà "sostituito" con le dipendenze incluse in questo pom come se fossero state originariamente definite qui.

Qual è la differenza tra la soluzione sopra e la semplice dipendenza da questo pom senza importscopo (ho visto quest'ultimo chiamato "raggruppamento delle dipendenze")? L'unica differenza è che tali dipendenze "raggruppate" hanno una priorità inferiore mentre risolvono la precedenza delle dipendenze?

— grafthez
fonte

187

Puoi importare solo dipendenze gestite . Ciò significa che puoi importare solo altri POM nella dependencyManagementsezione del POM del tuo progetto. vale a dire

...
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>other.pom.group.id</groupId>
            <artifactId>other-pom-artifact-id</artifactId>
            <version>SNAPSHOT</version>
            <scope>import</scope>
            <type>pom</type>
        </dependency>   
    </dependencies>
</dependencyManagement>
...

Quello che succede è che tutte le dipendenze definite nella dependencyManagementsezione del other-pom-artifact-idsono incluse nella dependencyManagementsezione del tuo POM . Puoi quindi fare riferimento a queste dipendenze nella dependencysezione del tuo POM (e di tutti i suoi POM figlio) senza dover includere un versionecc.

Tuttavia, se nel tuo POM definisci semplicemente una dipendenza normale, other-pom-artifact-idallora tutte le dipendenze dependenciesdalla dependencysezione di other-pom-artifact-idsono incluse transitivamente nel tuo progetto - tuttavia le dipendenze definite nella dependencyManagementsezione di other-pom-artifact-idnon sono incluse affatto.

Quindi fondamentalmente i due diversi meccanismi vengono utilizzati per importare / includere i due diversi tipi di dipendenze (dipendenze gestite e dipendenze normali).

C'è una buona pagina sul sito Web di Maven , che può spiegare questo molto meglio di me, Dependency Management in Maven e contiene anche informazioni specifiche sull'importazione delle dipendenze .

— DB5
fonte

1

Se pomA è il genitore di pomB, puoi inserire B nella gestione delle dipendenze del progetto A con ambito import?

— Janez Kuhar,

ottima risposta per spiegare come funziona, ma perché ?? perché non vuoi includere le altre dipendenze in modo transitorio? puoi anche fare entrambe le cose? importare other-pom-artifact-id e quindi dichiarare anche other-pom-artifact-id come dipendenza?

— Junchen Liu

Un articolo su DZone afferma qualcosa di diverso:

...   <dependencies>     <dependency>       <groupId>${project.groupId}</groupId>       <artifactId>pomlib-lib</artifactId>       <type>pom</type>       <scope>import</scope>     </dependency>     <dependency>       <groupId>${project.groupId}</groupId>       <artifactId>pomlib-war</artifactId>       <type>war</type>     </dependency>   </dependencies> </project>

DRY e Skinny War

— perché il

1

@ JunchenLiu: Quindi diciamo che stai usando solo un paio di funzionalità del progetto A, quindi puoi scegliere di includere solo quelle dipendenze transitive che sono richieste per quella funzione. Puoi risolverlo usando <exclude> anche in <dependency>. Ad esempio, controlla questo: jdbi.org/#_getting_started

— Nitiraj

15

Non puoi avere un pomprogetto di tipo come in un simple dependencyaltro progetto. (Bene, puoi, ma non farà nulla di utile). Può esserci solo una parent-childrelazione. Questo è essenzialmente managing dependency through inheritance.

importl'ambito della pomdipendenza dal tipo nella <dependencyManagement>sezione consente di ottenere l'equivalente di multiple inheritance.

Potresti avere diversi poms- ognuno managingun gruppo di dipendenze correlate. I progetti che li utilizzano potrebbero importquesti pomse quindi specificare le dipendenze di cui hanno bisogno senza doversi preoccupare della versione. Questo è essenzialmente il bill of materialsconcetto, che è illustrato nei collegamenti specificati da @ DB5.

Ciò aiuta a evitare che parent pomsprogetti complessi multi-modulo diventino troppo grandi e ingombranti.

— Raghuram
fonte

8

Sei sicuro? Ho inserito pom regolare (con le proprie dipendenze) come dipendenza regolare in un altro progetto (guerra dei pacchetti) e ho ottenuto tutte le dipendenze dal progetto pom incluse in WEB-INF / lib del progetto di destinazione. Ecco perché sto facendo questa domanda :)

— grafthez

2

Grazie @Raghuram, ho completamente dimenticato di menzionare l'opzione POM genitore quando ho risposto alla domanda. Per quanto riguarda avere un progetto di tipo pom come semplice dipendenza, questo è possibile. Come menzionato nella domanda originale, può essere utilizzato per raggruppare le dipendenze

— DB5

1

Link di lavoro sulle dipendenze di gruppo

— Vsevolod Golovanov

5

Due concetti, molto simili al paradigma di programmazione orientata agli oggetti, aiuteranno a rispondere alla domanda:

La sezione dependencyManagement dichiara solo le dipendenze ei loro dettagli nel progetto corrente - lo scopo è la gestione dei dettagli e il riutilizzo in altri progetti, tramite ereditarietà ( genitore ) o import ( ambito ). È come dichiarare un tipo di dati nel programma e renderlo disponibile per l'uso.
La sezione delle dipendenze definisce l'uso effettivo delle dipendenze nel progetto, opzionalmente eredita i dettagli (cioè, la versione, ecc.) Delle dipendenze dichiarate in dependencyManagment . Ecco perché mancheranno le dipendenze se le metti solo in dependencyManagment . Ciò è analogo alla creazione di un'istanza di una variabile di un tipo di dati in un programma in cui è necessario.

— furgone
fonte

È buono e chiaro ma risponde a una domanda diversa da quella sopra. :-)

— Rick-777