Cum se creează un ansamblu maven cu dependențe tranzitive pentru diferite scenarii de implementare?

Am o problemă la reconcilierea construirii unui proiect pentru a fi utilizat într-un server de aplicații și pentru a fi utilizat ca aplicație autonomă.

Pentru a oferi un context general simplificat, să spunem că am trei proiecte A, B, C.

Proiectul A depinde de Proiectul B, care depinde de Proiectul C.

Proiectul C are o dependență X care este marcată ca furnizată, deoarece era de așteptat să fie disponibilă ca bibliotecă JEE într-un server de aplicații, de exemplu. adică jms.jar.

Deci, dacă efectuez o construcție de asamblare a Proiectului A, primesc toate dependențele tranzitive cu excepția celor marcate ca fiind furnizate conform așteptărilor.

Acum am un nou scenariu de implementare în care Proiectul A trebuie utilizat într-un mediu autonom, adică în afara unui server de aplicații.

Deci acum am nevoie ca jms jar să fie o dependență de compilare. Înseamnă asta că ar trebui să adaug în mod explicit o dependență de compilare pentru X în Proiectul A? Acest lucru nu încalcă Legea lui Demeter, adică nu vorbiți cu străini, în sensul că Proiectul A nu ar trebui să știe în mod explicit despre Proiectul C, ci doar despre Proiectul B?

Acesta este un exemplu simplu, dar în realitate am mai multe dependențe care au fost marcate ca furnizate, dar acum trebuie să fie dependențe de compilare sau de rulare, astfel încât să ajungă în artefactul produs de pluginul de asamblare Maven.

Este aceasta o problemă fundamentală cu Maven sau nu folosesc instrumentele corect?

Multumesc anticipat pentru orice indrumare.


dependencies maven dependency-management maven-assembly-plugin assembly-resolution
person Afrogeek    schedule 17.05.2011    source sursă

Răspunsuri (2)


arrow_upward
0
arrow_downward

Dacă aveți nevoie ca versiunea dvs. să aibă variații pentru diferite scenarii, trebuie să utilizați profiluri și să păstrați anumite lucruri (cum ar fi unele dintre dependențe) în diferitele profiluri.

http://maven.apache.org/pom.html#Profiles

Diferite dependențe pentru diferite profiluri de compilare în Maven

răspunde la o întrebare similară - dar puteți schimba „lansarea” și „depanarea” cu „Proiectul A” și „Proiectul C”

person Ryan    schedule 17.05.2011

arrow_upward
0
arrow_downward

Cu condiția ca dependențele să fie un subiect dificil. În primul rând: dependențele furnizate sunt nu tranzitive în următorul sens: dacă proiectul dvs. C are o dependență furnizată de X, atunci A nu va primi dependența. Este ignorat în tăcere. Acest lucru se potrivește cu următorul sens al cuvântului „prevăzut” pe care îl propun:

Numai artefactele care sunt implementate efectiv ar trebui să marcheze dependențele ca „furnizate”. Bibliotecile sau alte borcane care nu sunt implementate individual pe un anumit server ar trebui să nu să fi furnizat dependențe. În schimb, ar trebui să-și declare dependențele ca dependențe de compilare. În exemplul dvs.: Proiectul C ar trebui să aibă o dependență de compilare de X. Dacă proiectul A știe că X este furnizat, îl setează pe X să fie furnizat în „dependencyManagement”. Deoarece proiectul A ar trebui să cunoască mediul în care rulează, acesta ar trebui să decidă ce este furnizat și ce nu. Iar „dependenyManagement” este locul potrivit pentru a declara acest lucru.

Dacă proiectul dvs. A ar trebui să poată rula în și fără un anumit server, probabil că trebuie să faceți o mulțime de ajustări, chiar să schimbați tipul de la ureche la borcan. Deci fie utilizați profiluri de construcție pentru aceasta, care apoi au intrări diferite de management al dependențelor, fie împărțiți A în două proiecte care depind de un alt proiect care conține elementele comune.

Dacă un anumit proiect C are deja o dependență furnizată de X și nu o puteți schimba, aceasta este efectiv la fel cu o dependență lipsă în C. Aceasta trebuie reparată la un moment dat și acesta ar putea fi chiar proiectul A.

person J Fabian Meier    schedule 20.03.2017