Jaka jest różnica między zasięgiem maven compilea providedbudowaniem artefaktu jako JAR? Gdyby to była WOJNA, zrozumiałbym - artefakt byłby włączony lub nie w WEB-INF / lib. Ale w przypadku JAR nie ma to znaczenia - zależności nie są uwzględniane. Muszą znajdować się w ścieżce klas, gdy ich zakres to compilelub provided. Wiem, że providedzależności nie są przechodnie - ale czy to tylko jedna różnica?
Odpowiedzi:
Z dokumentu Maven :
skompilować
Jest to zakres domyślny, używany, jeśli nie określono żadnego. Zależności kompilacji są dostępne we wszystkich ścieżkach klas projektu. Ponadto te zależności są propagowane do zależnych projektów.
opatrzony
Jest to bardzo podobne do kompilacji, ale wskazuje, że oczekujesz, że JDK lub kontener zapewni zależność w czasie wykonywania. Na przykład podczas budowania aplikacji WWW dla Java Enterprise Edition należy ustawić zależność od interfejsu API serwletu i powiązanych interfejsów API Java EE w zakresie podanym, ponieważ kontener WWW udostępnia te klasy. Ten zakres jest dostępny tylko w ścieżce klas kompilacji i testów i nie jest przechodni.
Podsumować:
compilei nie będzie, jeśli zakres jest provided.
Kompilacja oznacza, że potrzebujesz pliku JAR do kompilowania i uruchamiania aplikacji. Przykładowo w przypadku aplikacji internetowej plik JAR zostanie umieszczony w katalogu WEB-INF / lib.
Podane oznacza, że potrzebujesz pliku JAR do kompilacji, ale w czasie wykonywania istnieje już plik JAR dostarczony przez środowisko, więc nie potrzebujesz go w pakiecie z aplikacją. W przypadku aplikacji internetowej oznacza to, że plik JAR nie zostanie umieszczony w katalogu WEB-INF / lib.
W przypadku aplikacji internetowej, jeśli serwer aplikacji już udostępnia plik JAR (lub jego funkcjonalność), użyj „pod warunkiem”, w przeciwnym razie użyj „kompilacji”.
mvn exec:javajest uruchamiana, ale zależność skompilowana jest.
Jeśli planujesz wygenerować pojedynczy plik JAR ze wszystkimi jego zależnościami (typowy xxxx-all.jar), wówczas podany zakres ma znaczenie, ponieważ klasy w tym zakresie nie zostaną umieszczone w wynikowym pliku JAR.
Aby uzyskać więcej informacji, zobacz maven-assembly-plugin
maven-assembly-plugin, ciekawe, że w najczęściej głosowanych odpowiedziach nie ma o tym mowy.
- skompilować
Udostępnij w ścieżce klasy, nie dodawaj tej zależności do końcowego jar, jeśli jest to normalny jar; ale dodaj ten słoik do słoika, jeśli słoik końcowy jest pojedynczym słoikiem (na przykład słoik wykonywalny)
- opatrzony
Zależność będzie dostępna w środowisku wykonawczym, więc w żadnym wypadku nie dodawaj tej zależności; nawet nie w jednym słoiku (tj. słoik wykonywalny itp.)
W przypadku pliku jar różnica występuje w ścieżce klasy wymienionej w pliku MANIFEST.MF zawartym w pliku jar, jeśli parametr addClassPath ma wartość true w konfiguracji wtyczki maven-jar-plugin. W pliku manifestu pojawią się zależności „kompiluj”, a zależności „pod warunkiem” nie.
Jednym z moich podejrzeń jest to, że te dwa słowa powinny mieć ten sam czas. Albo skompilowany i udostępniony, albo skompilowany i udostępniony.
Po ustawieniu zakresu maven jako providedoznacza to, że po uruchomieniu wtyczki rzeczywista zastosowana wersja zależności będzie zależeć od zainstalowanej wersji Apache Maven.
Jeśli plik jar jest jak wykonywalny plik jar jar rozruchu wiosennego, wówczas zakres wszystkich zależności musi compileobejmować wszystkie pliki jar.
Ale jeśli plik jar używany w innych pakietach lub aplikacjach, nie musi uwzględniać wszystkich zależności w pliku jar, ponieważ te pakiety lub aplikacje mogą same zapewniać inne zależności.
JAR packagingkontekście. Doktor Maven nie wspomina o tym. Używam Maven przez jakiś czas, ale ja właśnie już zadawałem sobie pytanie o to :) Tak więc wydaje się, że wJAR packagingkontekście, nie ma żadnej różnicy międzycompileiprovided(z wyjątkiem przejścia zależności). Czy mam rację?