Ponieważ pracowałem z npm, który szuka zależności w pliku package.json i pobiera go za Ciebie. Podobnie widzę plik pom.xml w projekcie Java. Czy maven szuka w tym pliku i pobiera zależności dla mnie. Czy mogę przekazać ten plik pom.xml, taki jak package.json, zamiast podawać pliki jars zależności? Czy te narzędzia są podobne i są tworzone tylko dla różnych platform?
Odpowiedzi:
Maven to najpopularniejsze narzędzie do budowania i rozwiązywania zależności dla języka Java, podobnie jak NPM dla JS. Ale to nie jest tylko to samo narzędzie dla innego języka. Istnieją oczywiście ogromne różnice między kompilacjami Java i JS, a różnice te są bezpośrednio widoczne w sposobie działania Mavena. Na przykład, podczas gdy wiele narzędzi JS polega na Git, aby wykonać pewne ciężkie prace, Maven pracuje z niestandardowymi repozytoriami Maven opartymi na systemie plików, ponieważ Maven jest starszy od Gita i musi obsługiwać artefakty binarne, z którymi Git dawniej nie radził sobie dobrze. W Maven istnieje wyraźne oddzielenie źródeł od plików binarnych, podczas gdy w świecie JS często są one tym samym.
Maven w swojej najczystszej formie kieruje się modelem deklaratywnym, w którym pom.xml(podobnie package.json) definiuje różne właściwości kompilacji, ale nie zawiera skryptów. Wadą jest to, że dopracowanie niektórych aspektów kompilacji bez używania skryptów może być wyzwaniem, ponieważ musisz polegać na wtyczkach. Zaletą jest to, że łatwiej jest zrozumieć inne kompilacje, patrząc na nie pom.xml, ponieważ zwykle stosują to samo podejście bez zbytniego dostosowywania. Gradle jest popularnym narzędziem opartym na Groovy, opartym na standardach i konwencjach Maven, zaprojektowanym specjalnie w celu uproszczenia pom.xmli przełamania tej bariery „bez skryptu”.
Podobnie package.json, nie pracujesz bezpośrednio ze pom.xmlswoją zależnością, ale raczej definiujesz współrzędne zależności i pozwalasz narzędziu kompilacji zająć się resztą. W Maven podstawową formą tych współrzędnych jest GAV (groupId, artifactId, version).
Opierając się na komentarzach w drugiej odpowiedzi, Maven dostarcza „płaskie drzewo zależności”, a nie „zagnieżdżone drzewo zależności”, które NPM dostarcza domyślnie. Maven nie zezwala na wiele wersji tej samej zależności. Jeśli zdarzy się, że żądane są różne wersje, Maven używa rozwiązania zależności, aby wybrać jedną wersję. Oznacza to, że czasami zależności przechodnie otrzymają inną wersję niż wymagają, ale są sposoby, aby sobie z tym poradzić. Jednak to ograniczenie pochodzi z Javy, a nie Mavena, ponieważ (normalnie) w Javie program ładujący klasy zapewnia dostęp tylko do jednej definicji klasy, nawet jeśli w ścieżce klas znajduje się wiele definicji. Ponieważ Java nie radzi sobie z tym zbyt dobrze, Maven stara się przede wszystkim uniknąć tego scenariusza.
Uwaga: od npm v3 zależności są spłaszczane. Alternatywna przędza menedżera pakietów również robi to samo.
Co więcej, Maven jest znacznie starszy niż NPM, ma większą bazę użytkowników, ogromną liczbę niestandardowych wtyczek i jak dotąd można go prawdopodobnie uznać za bardziej dojrzały. Czasami Maven jest używany w projektach innych niż Java lub nawet w projektach poliglotowych, ponieważ istnieją wtyczki do obsługi innych języków lub określonych środowisk, takich jak Android. Istnieją wtyczki, które łączą Mavena i inne narzędzia do budowania, takie jak wtyczka frontend-maven-plugin, która faktycznie obsługuje wiele narzędzi do budowania JS.
Poniżej używam | do oddzielenia maven | terminy npm odpowiednio:
Oba narzędzia obsługują dynamiczne pobieranie zależności ( artefaktów | pakietów ) na podstawie pliku deskryptora pom.xml| package.json, a także umożliwia wdrażanie | publikuj własne artefakty | pakiety .
Obaj mają domyślne repozytorium publiczne | register ( http://repo.maven.apache.org/maven2/ | https://registry.npmjs.org ), ale można również użyć innych firm (przez settings.xml|.npmrc ).
Oba wspierają koncepcję zależności na poziomie kompilacji (wtyczki | devDependencies używane w skryptach) . * Maven obsługuje providedrównież zależności, ale wydaje się, że nie dotyczy to npm, ponieważ javascript jest rzadko wdrażany w kontenerach.
Oba obsługują przestrzeń nazw zależności: groupId|scope
maven ma dodatkowe repozytorium lokalne (cache):
zależności z projektu kompilowanego w maven są pobierane w <homedir>/.m2. Z npm są pobierane w formacie <projectdir>/node_modules.
Budowanie w maven jest zwykle procesem jednoetapowym : mvn package(pobieranie dokumentacji, budowanie). W npm jest to proces dwuetapowy: npm install(pobierz deps), npm build(build)
Maven definiuje kompilacji cyklu życia (do budowania, testowania, wdrażania) składała się z etapów, do których standardowe operacje (goals plugin) przymocowanie , w oparciu o differrent opcji opakowaniowych ( .jar, .war, .earetc). Możesz wtedy nadpisać te operacje lub wprowadzić nowe (za pośrednictwem systemu wtyczek). Zapewnia to rodzaj gotowego rozwiązania do kompilacji, docgen, testowania, wdrażania itp.Podejście
npm jest bardziej uproszczone (patrz: skrypty )
W związku z powyższym npm jest oznaczony jako narzędzie do zarządzania pakietami dla javascript, podczas gdy maven jest oznaczony jako narzędzie do automatyzacji kompilacji i zarządzania zależnościami dla java .
W Maven konfigurowanie procesu kompilacji częściej obejmuje edycję plikupom.xml .
W KMP wiąże pisania kodu lub konfiguracji komplementarne narzędzia kompilacji jak gulp, webpacketc
Z jakiegoś powodu zakresy wersji definiowane przez użytkowników w modułach npm są dużo bardziej luźne niż w maven. Może to powodować problemy z zależnościami przechodnimi, dlatego ostatnio dodano dodatkowy plik:package-lock.json
Z KMP jest o wiele bardziej proste, aby rozpocząć nowy projekt: npm init. Z mavenem musisz wiedzieć, jak napisać minimalizm pom.xmllub poczytać o archetypach.
Ogólnie znacznie częściej edytuje się pom.xmlniż package.json. Np. Dodawanie zależności w maven odbywa się ręcznie (lub przez IDE) w npm za pomocą wiersza poleceń .
Podobnie jak w przypadku wszystkich narzędzi do budowania, możesz wywołać jedno narzędzie z wnętrza drugiego, ale myślę, że znacznie częściej wywołuje się npm z wewnętrznego maven , niż odwrotnie.
npm obsługuje wersje deweloperskie, produkcyjne . W maven należy to zdefiniować za pomocą profili .
tak. jest to podobne narzędzie do pakowania dla java. szukaj gradlerównież tego, co daje ci więcej swobody groovy language, ale na początek możesz użyć mavendo uporządkowania swoich zależności. umieszczasz je tam jako tagi, a maven wykona pracę za Ciebie.
przechodzi przez drzewo zależności i pobiera wszystkie odpowiednie pliki JAR.
gradlejest maven + antrazem. robi to, co robi maven, ale daje również swobodę pisania kodu i skryptów poza wszystkimi faktycznymi zadaniami, które wykonuje. gulpWłaśnie się temu przyjrzałem . może to to samo, z tego co przeczytałem. jeśli chcesz zacząć używać maven vs gradle, proponuję zacząć od tego, mavenco jest bardziej przejrzyste i łatwiejsze do zrozumienia, a następnie zepsuć gradle!
Tak, to samo z gradle, ale nie są one przyjazne dla użytkownika jak npm.