pom.xml und setts.xml
pom.xml und seting.xml können die beiden wichtigsten Konfigurationsdateien in Maven sind, die die Kernfunktionen von Maven bestimmt. Obwohl die vorherigen Artikel den Inhalt in pom.xml und setting.xml in Fragmenten erwähnten, werden sie alle kurz erwähnt, und das Lernen und die Forschung sind nicht detailliert. Der Zweck dieses Artikels ist es, diese beiden wichtigen Konfigurationsdateien im Detail zu untersuchen. Diese beiden Konfigurationsdateien können zu vielen Maven -Themen führen.
Maven -Koordinaten
Lassen Sie uns zunächst darüber sprechen, warum wir Maven -Koordinaten verwenden müssen.
Die Maven -Welt hat eine sehr große Anzahl von Komponenten, dh einige Glas-, Kriegs- und andere Dateien, die normalerweise verwendet werden. Bevor Maven das Konzept der Koordinaten für diese Komponenten einführt, können wir keine Methode verwenden, um alle diese Komponenten eindeutig zu identifizieren. Wenn Sie also Frühlingsabhängigkeiten verwenden müssen, gehen Sie daher zur Suche auf die offizielle Spring -Website, um zu suchen. Wenn Sie Log4J -Abhängigkeiten verwenden müssen, gehen Sie zur Suche auf die offizielle Apache -Website, um zu suchen. Aufgrund der verschiedenen Stile jeder Website wird viel Zeit für das Suchen und Durchsuchen von Webseiten aufgewendet. Ohne einheitliche Normen und Regeln kann die Arbeit nicht automatisiert werden, und es sollten sich wiederholende Arbeitskräfte Maschinen überlassen werden.
Maven definiert eine Reihe von Regeln: Jede Komponente der Welt kann durch Maven -Koordinaten eindeutig identifiziert werden. Zu Maven -Koordinatenelementen gehören GroupID, Artefaktid, Version, Verpackung und Klassifizierer. Solange wir die korrekten Elementkoordinaten bereitstellen, kann Maven die entsprechende Komponente finden. Wie man heruntergeladen wird, hat Maven selbst eine integrierte Adresse eines zentralen Lagerhauses "http://repo1.maven.org/maven2". Das zentrale Lagerhaus enthält die meisten beliebten Open -Source -Projektkomponenten der Welt. Mavne wird sie bei Bedarf herunterladen. Natürlich können Sie auch Ihre eigene zentrale Lageradresse konfigurieren und Komponenten in Ihrem eigenen zentralen Lager herunterladen.
Zum Beispiel den Kontext von Spring:
<Depopenty> <gruppe> org.springFramework </Groupid> <artifactId> Spring-Context </artifactId> <version> 4.2.6.Release </Version> </Abhängigkeit
Schauen Sie sich die Elemente des Untergebenen an:
Dies ist ungefähr das Konzept der Maven -Koordinaten. Das Verständnis von Maven -Koordinaten ist ein sehr wichtiger Schritt zum Verständnis von Maven.
Transitive Abhängigkeit
Was ist transitive Abhängigkeit? Nehmen Sie als Beispiel den Frühling. Bei der Verwendung des Frühlings verlassen Sie sich auf andere Open -Source -Klassenbibliotheken. Es gibt zwei Möglichkeiten, dies zu tun:
1. Laden Sie ein großes .zip -Paket herunter, das alle Frühlingsgläser enthält, führt jedoch oft viele unnötige Abhängigkeiten ein
2. Laden Sie nur Federbezogene .zip-Pakete herunter, enthalten keine Abhängigkeiten. Fügen Sie bei der Verwendung weitere Abhängigkeiten hinzu, die gemäß den Fehlerinformationen erforderlich sind.
Offensichtlich sind beide Ansätze sehr problematisch, und der transitive Abhängigkeitsmechanismus von Maven löst dieses Problem gut. Öffnen Sie die Pom.xml von Spring-Core-4.1.0.Release, und ich fasse einen Schlüsselteil ab:
<dependencies> <dependency> <groupId>commons-codec</groupId> <artifactId>commons-codec</artifactId> <version>1.9</version> <scope>compile</scope> <optional>true</optional> </dependency> <dependency> <groupId>commons-logging</groupId> <artifactId>commons-logging</artifactId> <version> 1.1.3 </version> <scope> kompilieren </scope> </abhängig> ... </abhängig>
Beispielsweise hängt ein Projekt A abhängig von Spring-Core ab, Spring-Core hängt von Commons-CODEC und Commons-Logging ab. Daher sind Commons-CODEC und Commons-Logging transitive Abhängigkeiten von Projekt A. Mit dem transitiven Abhängigkeitsmechanismus müssen Sie bei der Verwendung von Spring-Core nicht überlegen, worauf es abhängt, und Sie müssen sich keine Sorgen über die Einführung unnötiger Abhängigkeiten machen. Maven wird jede direkte Abhängigkeits -POM analysieren und die erforderlichen indirekten Abhängigkeiten in das aktuelle Projekt in Form von transitiven Abhängigkeiten in das aktuelle Projekt einführen.
Mit dem transitiven Abhängigkeitsmechanismus einerseits vereinfacht er die Abhängigkeitserklärung erheblich und erleichtert es. Andererseits müssen wir uns in den meisten Fällen nur darum kümmern, was die direkten Abhängigkeiten des Projekts sind, und müssen nicht überlegen, welche transitiven Abhängigkeiten von diesen direkten Abhängigkeiten eingeführt werden. Manchmal haben transitive Abhängigkeiten jedoch auch einige Probleme. Zu diesem Zeitpunkt müssen wir den Pfad löschen, aus dem die transitive Abhängigkeit eingeführt wurde. Dies wird als Abhängigkeitsmediation bezeichnet. Es gibt zwei Hauptprinzipien der Abhängigkeitsvermittlung:
1. A-> B-> C-> X (1,0), A-> D-> X (2.0), zu diesem Zeitpunkt gibt es zwei Versionen von x auf den beiden Abhängigkeitspfaden. Zu diesem Zeitpunkt wird der engste Weg bevorzugt, sodass X (2.0) analysiert und verwendet wird.
2. Die Abhängigkeitslängen von a-> b-> y (1,0), a-> c-> y (2,0), y (1,0) und y (2,0) sind gleich. Ab Maven2.0.9 folgt die erste Aussage der Priorität, dh der Abhängigkeit von der höchsten Ordnung wird bevorzugt.
Abhängigkeiten ausschließen
Transitive Abhängigkeiten werden dem Projekt implizit eine Menge Abhängigkeiten einführen, was das Management von Projektabhängigkeiten erheblich vereinfacht, aber manchmal kann diese Funktion auch Probleme verursachen. Zum Beispiel gibt es eine Situation:
Das aktuelle Projekt hängt von A abhängig von der Snapshot -Version einer anderen Klassenbibliothek aus irgendeinem Grund ab. Dann wird dieser Schnappschuss zu einer transitiven Abhängigkeit des aktuellen Projekts. Zweitens wirkt sich die Instabilität von Snapshot direkt auf das aktuelle Projekt aus. Zu diesem Zeitpunkt muss der Snapshot ausgeschlossen werden und eine formelle Version der Klassenbibliothek wird im aktuellen Projekt deklariert.
Es ist sehr einfach, Abhängigkeiten auszuschließen. Schauen wir uns die Schreibmethode an:
<dependency> <groupId>com.alibaba.rocketmq</groupId> <artifactId>rocketmq-client</artifactId> <version>3.2.7</version> <exclusions> <exclusion> <groupId>apache-lang</groupId> <artifactId>commons-lang</artifactId> </exclusion> </exclusions></dependency>
Hier habe ich die Abhängigkeit von RocketMQ eingeführt, aber ich möchte mich nicht auf Apache-Lang in Rocketmq verlassen, sondern auch auf mich selbst abhängige Abhängigkeiten einführen, also habe ich Apache-Lang ausgeschlossen.
Es ist hier zu beachten, dass bei der Erklärung des Ausschlusses nur GroupID und Artefaktid erforderlich sind und keine Versionselemente benötigt werden. Dies liegt daran, dass nur GroupID und Artefaktid erforderlich sind, um eine Abhängigkeit im Abhängigkeitsgraphen eindeutig zu lokalisieren. Mit anderen Worten, in den analysierten Abhängigkeiten von Maven ist es unmöglich, zwei Abhängigkeiten mit derselben Gruppen- und Artefaktis, aber mit unterschiedlichen Versionen zu haben.
Einstellungen.xml
Settings.xml ist die grundlegende Konfiguration von Maven. Es gibt viele Elemente, also schauen wir es uns nacheinander an.
1. Proxy
Proxy bedeutet Mavens Proxy. Schauen wir uns die Schreibmethode an:
<Proxies> <Proxy> <ID> Optional </id> <Active> true </active> <Protokol> http </protocol> <BENSERNAME> proxyuser </userername> <kennwort> proxypass </password> <host> proxy.host.net </host> <port> 80 </port> <nichtProxyHosts> local.net | einige.host.com </nonproxyhosts> </proxy> </proxies>
Proxy wird benötigt, da Ihr Unternehmen oft auf das Internet zugreifen muss, indem Sie einen Sicherheits -zertifizierten Proxy basierend auf Sicherheitsüberlegungen basieren. In diesem Fall müssen Sie einen HTTP -Proxy für Maven konfigurieren, damit er normalerweise auf das externe Repository zugreifen kann, um die erforderlichen Ressourcen herunterzuladen. Mehrere Proxyelemente können unter Proxies konfiguriert werden. Wenn mehrere Proxyelemente deklariert werden, wirkt sich der erste aktivierte Proxy standardmäßig in Kraft. Active ist wahr, um den Proxy zu aktivieren. Das Protokoll repräsentiert das verwendete Proxy -Protokoll, das natürlich das Wichtigste ist, den richtigen Hostnamen (Host) und den Port (Port) anzugeben. Wenn der Proxy -Server Authentifizierung benötigt, konfigurieren Sie den Benutzernamen und das Kennwort. Das Nicht -Proxyhost -Element gibt an, welche Hostnamen keinen Proxy benötigen. Sie können "|" verwenden Mehrere Hostnamen zu trennen und auch Wildcard "*" zu unterstützen.
2. Repository
Das Repository repräsentiert Mavens zentrales Lagerhaus, denn obwohl die Komponenten im Standard -Remote -Lager sehr groß sind, werden es immer Zeiten geben, in denen sie unsere Bedürfnisse nicht erfüllen, und dann werden andere zentrale Lagerhäuser verwendet. Schauen wir uns die Schreibmethode an:
<Repository> <ID> public </id> <name> Lokaler privater Nexus </name> <URL> http://192.168.1.6:8081/nexus/content/groups/public </url> <releases> <enabled> truable </enabled> </releasses> </snapshots> <disabled> </releasses> <- </snapshots> </repository>
Mehrfaches Repository kann deklariert werden. Die ID muss eindeutig sein. Achten Sie besonders darauf, dass die vom zentralen Repository verwendete ID, mit der Maven ausgestattet ist, zentral ist. Wenn andere Repository -Deklarationen diese ID ebenfalls verwenden, wird die Konfiguration des zentralen Repositorys überschrieben. Veröffentlichungen und Schnappschüsse sind wichtiger. Ersteres bedeutet, die Unterstützung für das Repository zu öffnen, und letztere bedeutet, die Support für das Repository für die Snapshot -Version herunterzuladen. Auf diese Weise wird Maven zum Repository gehen, um die Version des Repositorys herunterzuladen, ohne die Snapshot -Version des Repositorys herunterzuladen.
3. Server
Auf die meisten abgelegenen Lagerhäuser können ohne Authentifizierung zugegriffen werden. Manchmal werden sie jedoch in Sicherheitsfaktoren berücksichtigt und müssen Authentifizierungsinformationen bereitstellen, um auf einige Remote -Lagerhäuser zuzugreifen. Bei Sicherheitsüberlegungen werden Authentifizierungsinformationen im Allgemeinen nur in settings.xml platziert, und der Server ist das Authentifizierungselement. Schauen Sie sich die Konfiguration an:
<Server> <ID> Nexus-Releases </id> <Benutzung> Bereitstellung </userername> <kennwort> Bereitstellung </Passwort> </server>
Der Schlüssel hier ist die ID. Diese ID muss genau der ID des Repositiry -Elements entsprechen, das authentifiziert werden muss. Mit anderen Worten, die formale ID verknüpft die Authentifizierungsinformationen und die Repository -Konfiguration.
4. Spiegel
Wenn Warehouse X alle Inhalte liefern kann, die in Lagerhaus y gespeichert sind, kann Warehouse X als Spiegel von Warehouse Y angesehen werden. Mit anderen Worten, jede Komponente, die aus y erhalten werden kann "http://repo1.maven.org/maven2/" in China. Aufgrund geografischer Standortfaktoren kann der Spiegel häufig schnellere Dienstleistungen anbieten als das zentrale Lagerhaus, weshalb Mirror verwendet wird.
Schauen Sie sich die Konfiguration des Spiegels an:
<Mirror> <ID> Nexus </id> <name> Interne Nexus -Repository </name> <URL> http://192.168.1.6:8081/nexus/content/groups/public </url> <mirrorof>*</minorof> </minor>
In diesem Beispiel ist Mirrorf *, was darauf hinweist, dass die Konfiguration ein Spiegel für alle zentralen Repositorys ist und alle Anforderungen für das zentrale Repository in den Spiegel übertragen werden. Die anderen drei Elemente -IDs, der Name und die URL unterscheiden sich nicht von der allgemeinen Lagerkonfiguration und repräsentieren die eindeutige Kennung, den Namen und die Adresse des Spiegellagers. Wenn das Bild eine Authentifizierung erfordert, kann die Repository -Authentifizierung auch basierend auf der ID konfiguriert werden.
Danke fürs Lesen, ich hoffe, es kann Ihnen helfen. Vielen Dank für Ihre Unterstützung für diese Seite!