Was ist ein Maven -Lagerhaus?
Wenn wir Maven beispielsweise in der Vergangenheit nicht verwenden, haben wir häufig Projekte mit ANT erstellt, wir sehen häufig ein Unterverzeichnis namens /lib, das verschiedene Abhängigkeitsdateien von Drittanbietern speichert, wie z. B. log4j.jar, junit.jar usw.
Jedes Mal, wenn Sie ein Projekt erstellen, müssen Sie ein A /Lib -Verzeichnis erstellen und dann ein Paar JAR -Dateien kopieren, was eine offensichtliche Vervielfältigung ist. Wiederholung ist immer der Ausgangspunkt eines Albtraums. Mehrere Projekte teilen nicht die gleiche JAR -Datei, die nicht nur Verschwendung von Festplattenressourcen verursacht, sondern auch das Konsistenzmanagement von Versionen erschwert.
Wenn Sie Versionenverwaltungs -Tools wie SVN verwenden (Sie verwenden keine Versionenverwaltungs -Tools? Versuchen Sie es mit SVN, können Sie jetzt viele Kopfschmerzen lösen), müssen Sie eine große Anzahl von JAR -Dateien in die Code -Bibliothek senden, aber Versionsmanagement -Tools sind bei Binärdateien nicht hervorragend.
In dem Maven -Repository werden alle JAR -Dateien (Krieg, Reißverschluss, Pom usw.) platziert. Alle Maven -Projekte können das Abhängigkeitsglas erhalten, das sie aus demselben Maven -Repository benötigen, das die Festplattenressourcen spart. Da alle Gläser im Maven -Repository über eigene Koordinaten verfügen, die Maven seine Gruppen -ID, Komponenten -ID, Version, Verpackungsmethode usw. mitteilen, kann das Maven -Projekt problemlos die Abhängigkeitsversionsverwaltung durchführen. Sie sind nicht verpflichtet, JAR-Dateien an das SCM-Repository zu senden. Sie können ein Maven-Repository auf Organisationsebene für alle Mitglieder erstellen.
Kurz gesagt, Maven Repository hilft uns, Artefakte (hauptsächlich Gläser) zu verwalten.
In Maven kann die Ausgabe jeglicher Abhängigkeit, Plug-in oder Projektkonstruktion als Komponente bezeichnet werden.
Maven speichert alle gemeinsam genutzten Komponenten aller Projekte an einem einheitlichen Ort. Dieser einheitliche Standort wird als Lagerhaus bezeichnet. (Im Lagerhaus werden Abhängigkeiten und Plug-Ins gespeichert)
Jede Komponente hat eine einzigartige Koordinate. Maven definiert den einzigartigen Speicher der Komponente im Lager basierend auf dieser Koordinate.
Interpretieren Sie den Speicherpfad von Maven im Repository:
1. Bereiten Sie den Pfad basierend auf GroupID vor, konvertieren Sie den Periodenabscheider in den Pfadabscheider, dh konvertieren "". Zu "/" ; Beispiel: org.testng ---> org/testng
2. Bereiten Sie den Pfad auf basierend auf Artefaktis vor und verbinden
3. Verwenden Sie die Version, um den Pfad vorzubereiten und die Version mit der Rückseite zu verbinden: org/testng/testng/5.8
V.
5. Beurteilung, ob die Komponente einen Klassifizierer hat, fügen Sie den Trennzeichen nach Punkt 4 hinzu und fügen Sie den Klassifizierer, org/testng/testng/5.8/tesng-5.8-Jdk5 hinzu
6. Überprüfen Sie die Erweiterung der Komponente. Wenn die Erweiterung vorhanden ist, fügen Sie den Periodenabscheider und die Erweiterung hinzu. Die Erweiterung wird durch Packung, org/testng/testNG/5.8/tesng-5.8-Jdk5.jar bestimmt
Zu diesem Zeitpunkt verstehen wir die Details der Speicherung von Mavens Komponenten.
Klassifizierung von Maven Warehouse:
Maven's Warehouse hat nur zwei Kategorien: 1. Lokales Lager 2. Remote Warehouse, das in drei Arten in Remote -Lagern unterteilt ist: 2.1 Zentrallager 2.2 Privatserver 2.3 Weitere öffentliche Lagerhäuser
1. Das lokale Lagerhaus speichert, wie der Name schon sagt, die Komponenten vor Ort.
Hinweis: Das lokale Repository von Maven wird nach der Installation von Maven nicht erstellt. Es wird nur erstellt, wenn der Befehl maven zum ersten Mal ausgeführt wird.
Der Standardstandort von Maven Local Repository: Unabhängig davon, ob es sich bei Windows oder Linux handelt, befindet sich ein .M2/ Repository/ Repository -Verzeichnis im Benutzerverzeichnis. Dies ist der Standardstandort des Maven -Repositorys.
So ändern Sie den Standort von Mavens Standard lokaler Repository: Hier möchten wir ein neues Element vorstellen: LocalRepository, das in Mavens Einstellungen vorhanden ist
1.1 Ändern Sie das lokale Repository, das benutzerweit konfiguriert wird: Erstellen Sie zuerst Einstellungen.xml-Datei in /.m2/ Verzeichnis und setzen Sie dann den Wert des LocalRepository-Elements auf die gewünschte Repository-Adresse in ~/.m2/Settings.xml.
<Seteds> <Lococrepository> d:/maven_new_repository </localrepository> </Einstellungen>
Zu diesem Zeitpunkt wird die lokale Repository -Adresse von Maven D:/maven_new_repository. Hinweis: Das zu diesem Zeitpunkt konfigurierte lokale Repository von Maven gehört zum Benutzerumfang.
1.2 Ändern Sie die Konfiguration globalweites lokales Repository: Ändern Sie die Konfiguration in m2_home/conf/setting.xml. Die Methode zur Änderung der Konfiguration ist die gleiche wie oben
Hinweis: Nach dieser Änderung sind alle Benutzer betroffen, und wenn Maven aktualisiert wird, werden alle Konfigurationen gelöscht, sodass Sie die Datei m2_Home/conf/Settings.xml im Voraus kopieren und sichern müssen.
Daher: Unter normalen Umständen wird die Konfiguration globaler Einstellungen.xml nicht empfohlen.
2. Remote -Repository
2.1 Wenn es um abgelegene Lagerhäuser geht, beginnen Sie mit dem zentralsten Lagerhaus. Das zentrale Lagerhaus ist das Standard -Remote -Lagerhaus. Wenn Maven installiert ist, wird die Konfiguration des zentralen Lagerhauses geliefert.
In Maven Aggregation und Erbschaft haben wir gesagt, dass alle Maven -Projekte Super Pom erben werden. Insbesondere, wenn der Pom, der die folgenden Konfigurationen enthält, nennen wir es Super Pom
<repositories> <repository> <id>central</id> <name>Central Repository</name> <url>http://repo.maven.apache.org/maven2</url> <layout>default</layout> <snapshots> <enabled>false</enabled> </snapshots> </repository> </repository>
Das zentrale Lagerhaus enthält die beliebtesten Open -Source -Java -Komponenten sowie Quellcode, Autoreninformationen, SCM, Informationen, Lizenzinformationen usw. Im Allgemeinen können einfache Java -Projektabhängigkeiten hier heruntergeladen werden
2.2 Privatserver
Private Server ist ein spezielles Remote -Lagerhaus. Es ist ein Lagerservice im LAN. Private Server repräsentieren Remote -Lagerhäuser auf dem WAN für Maven -Benutzer im LAN. Wenn Maven Komponenten herunterladen muss, wird es vom privaten Server angefordert. Wenn die Komponente auf dem privaten Server nicht vorhanden ist, wird sie von einem externen Remote -Repository heruntergeladen, es auf dem privaten Server zwischengespeichert und anschließend Dienste für die Downloadanforderung von Maven bereitgestellt. Wir können auch einige Komponenten hochladen, die nicht von externen Lagerhäusern auf private Server heruntergeladen werden können.
Funktionen von Maven Private Server:
1. Speichern Sie Ihre eigene externe Netzwerkbandbreite: Reduzieren Sie den externen Netzwerkbandbreitenverbrauch durch wiederholte Anfragen
2. Beschleunigen Sie die Maven -Komponente: Wenn das Projekt mit vielen externen Fernlagern konfiguriert ist, wird die Konstruktionsgeschwindigkeit stark reduziert.
3.. Komponenten von Drittanbietern bereitstellen: Wenn einige Komponenten nicht von externen Lagerhäusern erhalten werden können, können wir diese Komponenten für interne Lagerhäuser (private Server) zur Verwendung durch interne Maven-Projekte bereitstellen.
V. Einige private Serversoftware bieten auch andere Funktionen.
5. Reduzieren Sie die Ladung des zentralen Lagerhauses: Die Anzahl der Anfragen für Maven Central Lagelhäuser ist enorm, und das Konfigurieren privater Server kann auch den Druck des zentralen Lagerhauses erheblich verringern.
Der aktuelle Mainstream Maven Private Server:
1.APache's Archiva
2.Jfrogs Artefaktor
3. Sonatype Nexus
3. Konfiguration Remote Warehouse
Das Konfigurieren des Remote -Repositorys führt neue Konfigurationselemente ein: <Repositories> <Prepository>
Unter dem Element <Repositories> können Sie das untergeordnete Element <Repository> verwenden, um eine oder mehrere Remote -Repositories zu deklarieren.
Beispiel:
<Repository> <ID> JBOSS </id> <name> JBOSS-Repository </name> <URL> http://repository.jboss.com/maven2/ </url> <releases> <UpdodesPolicy> Daily </updatePolicy> <! <ChecksUpolicy> WARN </ChecksUmpolicy> <!-Fail, Ignore-> </releases> <snapshots> <enabled> false </enabled> </snapshots> <layout> Standard </layout> </repository> </repository> </repository>
<UPDATEPOLICY> Element: Repräsentiert die Aktualisierungsfrequenz, die Werte sind: Niemals, immer, täglich, täglich sind die Standardwerte
<ChecksUpolicy> Element: Repräsentiert die Richtlinie von Maven, um Dateien zu überprüfen und zu überprüfen. Warn ist der Standardwert aus Sicherheitsgründen. Manchmal müssen wir den Zugriff des Remote -Lagerhauses authentifizieren. Im Allgemeinen sind die Authentifizierungsinformationen in setts.xml konfiguriert:
<Servers> <server> <ID> Gleiches gilt für die Repository -ID in POM </id> <BENSERNAME> Benutzername </userername> <password> pwd </password> </server> </servers>
Hinweis: Die ID hier muss mit der ID des Repository -Elements übereinstimmen, das im POM authentifiziert werden muss.
So Bereitstellung generierter Projekte für Remote -Repositories
Um diese Arbeit zu erledigen, müssen Sie sie auch im POM konfigurieren. Hier ist ein neues Element: <DistributionManagement>
DistributionManagement enthält 2 untergeordnete Elemente: Repository und Snapshotrepository. Ersteres repräsentiert das Repository für die Veröffentlichung der Versionskomponente, und letzteres repräsentiert das Repository für Snapshot -Version.
Beide Elemente müssen die ID (die eindeutige Kennung des Remote -Repositorys), den Namen, die URL (darstellen die Adresse des Repositorys) konfigurieren.
Die Bereitstellung von Komponenten in Remote -Lagerhäusern erfordert eine Authentifizierung. Die Konfiguration ist die gleiche wie oben
Laufen nach der Konfiguration ist korrekt: MVN Clean Bereitstellung
Schauen Sie sich Schnappschüsse richtig an
Bei der Konfiguration von POM waren wir vor der Konfiguration der Snapshots sehr vorsichtig oder die Snapshot -Version selten verwendet. Der Grund dafür ist, dass es immer noch sehr instabil ist und sehr leicht zu unbekannten Fehlern in unserem System zu verursachen ist, was es für uns schwer macht, es zu finden. Tatsächlich ist die Snapshot -Version nicht nutzlos. Der größte Zweck von Snapshot ist die Verwendung im Entwicklungsprozess, insbesondere wenn es Modulabhängigkeiten gibt. Zum Beispiel werden A und B gleichzeitig entwickelt. A Abhängig von B. Während des Entwicklungsprozesses sind A und B ständig integrierte Entwicklung, wodurch die POM -Dateien ständig geändert und Projekte erstellt werden. Zu diesem Zeitpunkt wird die Versionssynchronisation zu einem großen Problem. Dies kann mit Schnappschüssen erreicht werden.
Während der Veröffentlichung der Snapshot -Version markiert Maven die Komponente automatisch mit dem aktuellen Zeitstempel. Mit diesem Zeitstempel finden wir jederzeit die neueste Snapshot -Version, die das Problem der gerade erwähnten kollaborativen Entwicklung lösen wird.
Wie A überprüft das Update von b
Wir können auch die Befehlszeile verwenden, um Parameter hinzuzufügen, um Maven zu erzwingen, um nach Updates zu überprüfen: mvn clean install-U
Wie genau analysiert Maven Komponenten aus dem Lagerhaus? ---- Mavens Mechanismus zum Parsen von Abhängigkeiten vom Repository
1. Wenn der Umfang der Abhängigkeit System ist, löst Maven die Komponente direkt aus dem lokalen Dateisystem auf.
2. Versuchen Sie nach Berechnung des Lagerpfads auf den Abhängigkeitskoordinaten, Komponenten direkt aus dem lokalen Lagerhaus zu finden. Wenn die entsprechende Komponente gefunden wird, ist die Auflösung erfolgreich.
3. In dem Fall, in dem keine entsprechende Komponente im lokalen Repository vorhanden ist, iteratiert es, wenn die abhängige Version die angezeigte Release -Versionskomponente ist, alle Remote -Repositories durch und lädt sie nach der Entdeckung herunter.
V.
5. Wenn die abhängige Version Snapshot ist, wird die Metadaten aller Remote -Repositories basierend auf der Update -Richtlinie gelesen, mit den entsprechenden Metadaten des lokalen Repositorys zusammengeführt und den Wert der neuesten Snapshot -Version abrufen und dann das lokale Repository basierend auf dem Wert oder Download IT vom Remote -Repository überprüfen.
6. Wenn die letzte Parsen-Artefaktversion ein Schnappschuss des Zeitstempelformats ist, kopieren Sie die Datei in ihrem Zeitstempelformat in ein Nicht-Timetamp-Format und verwenden Sie das Artefakt in diesem Nicht-Timetamp-Format.
HINWEIS: Machen Sie sich unbedingt <Release> <enabled> & <Napshot> <enable>, dasselbe gilt für Schnappschüsse
Die neueste & Veröffentlichung wird bei der Deklarierung von POM nicht empfohlen. Die neueste & Version in der Plug-in-Konfiguration wird in Maven3 nicht mehr unterstützt. Wenn die Plug-in-Version nicht festgelegt ist, entspricht die endgültige Version mit der Veröffentlichung.
Maven wird nur die neuesten Release -Builds analysieren.
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.