Wie Sonatype Nexus 1.9 meinen Tag ruiniert hat

Update, 26-02: Brian Demers von Sonatype hat in den Kommentaren darauf hingewiesen, dass Maven 2.0.10 und spätere Versionen mit den Änderungen im Metadatenformat vorwärtskompatibel sind. Wenn Ihre Maven 2-Version eine der empfohlenen Versionen auf der Download-Seite ist, werden Sie dieses Problem nicht haben. Zwei Tage, um genau zu sein. Gestern Abend, nachdem meine Kollegen nach Hause gegangen waren, habe ich unsere Nexus 1.8.0.1-Instanz heruntergefahren, um sie auf 1.9 zu aktualisieren, ohne ihre Arbeit zu unterbrechen. Die Download-Seite für Nexus 1.9 enthält die folgende Anweisung:

Sonatype hat die Art und Weise geändert, wie die Lucene-Indizes auf der Festplatte gespeichert werden. Benutzer müssen alle Repositories in ihrem Nexus-Server neu indizieren, um von den Änderungen zu profitieren (und damit die Suche richtig funktioniert).

Unauffällig genug. Wenn Sie sich von der Änderungsübersicht zum vollständigen Änderungsprotokoll durchklicken, sehen Sie außerdem:

[NEXUS-3849] - Vollständige Unterstützung für die neuen Maven 3 Snapshot-Metadaten hinzufügen

Was Sie nicht sehen, ist, dass der Befehl rebuild metadata in der Repository-Verwaltung, der bei der Neuindizierung der Repositories eigentlich eine saubere Sache sein sollte, jetzt Metadaten im Stil von Maven 3 erzeugt und versehentlich die Kompatibilität mit Maven 2(Update: ältere Versionen) unterbricht. Hier beginnt der Spaß.

Der Spaß

Nachdem ich Nexus auf 1.9 aktualisiert und die Metadaten und Repositories neu indiziert hatte, begannen meine Jenkins-Builds zu scheitern: [sourcecode language="text"] [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Fehler beim Abrufen der vorherigen Build-Nummer für das Artefakt 'myGroup:myArtifact:pom': Cannot read metadata from '/home/maven/maven-repository/myGroup/myArtifact/1.8.0-SNAPSHOT/maven-metadata-nexus-snapshots.xml': expected START_TAG or END_TAG not TEXT (position: TEXT seen ...<extension>[/sourcecode] pom </... @14:25) Wer hätte das gedacht, Maven 2 Builds können nicht mit dem neuen Metadatenformat umgehen. (Ich finde es erwähnenswert, dass, wenn Jenkins eine neue Version herausgibt, alles einfach funktioniert. Sie haben die Kurve gekriegt, und zwar auf fantastische Weise).

Versuchte Lösung: Nexus herunterstufen

Meine vorherige Nexus-Version befindet sich immer noch im Dateisystem. Um ein Downgrade durchzuführen, musste ich nur Nexus beenden, den Symlink zurücksetzen und Nexus starten. [sourcecode language="text"] jvm 1 | 2011-02-24 18:30:28 ERROR [er_start_runner] - o.s.n.DefaultNexus - Konnte Nexus nicht starten, Ausnahme bei der Benutzerkonfiguration! jvm 1 | org.sonatype.configuration.upgrade.UnsupportedConfigurationVersionException: Nicht unterstützte Konfigurationsdatei in /home/maven/nexus-oss-webapp-1.8.0.1/./../sonatype-work/nexus/conf/nexus.xml mit Version: 1.4.4. Upgrade nicht möglich. [/sourcecode] Oh Mist. Wenigstens ist die Fehlermeldung klar und deutlich. Noch besser: Es stellt sich heraus, dass es eine nexus.xml.bak im conf-Verzeichnis gibt. Zum ersten Mal an diesem Abend murmle ich etwas Dankbares über Sonatype. Jetzt muss ich nur noch das gesamte conf-Verzeichnis an einen sicheren Ort kopieren, diese Backup-Konfigurationsdatei wiederherstellen und es erneut versuchen. [sourcecode language="text"] jvm 1 | 2011-02-24 18:39:21 INFO [er_start_runner] - o.s.n.c.a.DefaultNe~ - Laden der Nexus-Konfiguration... jvm 1 | 2011-02-24 18:39:21 INFO [er_start_runner] - o.s.n.c.s.StaticCon~ - Konfiguration erfolgreich geladen. [/sourcecode] ...so weit so gut... [sourcecode language="text"] jvm 1 | 2011-02-24 18:39:22 ERROR [er_start_runner] - o.s.g.b.r.NamedClass - Fehler beim Injizieren: org.sonatype.nexus.DefaultNexus jvm 1 | com.google.inject.ProvisionException: Guice-Bereitstellungsfehler: jvm 1 | jvm 1 | 1) Fehler beim Starten: Klasse org.sonatype.nexus.DefaultNexus jvm 1 | beim Auffinden von org.sonatype.nexus.DefaultNexus (gekürzt) jvm 1 | Verursacht durch: java.lang.NullPointerException jvm 1 | at org.sonatype.security.configuration.DefaultSecurityConfigurationManager.getRealms(DefaultSecurityConfigurationManager.java:104) jvm 1 | at org.sonatype.security.DefaultSecuritySystem.getRealmsFromConfigSource(DefaultSecuritySystem.java:202) jvm 1 | at org.sonatype.security.DefaultSecuritySystem.start(DefaultSecuritySystem.java:846) jvm 1 | at org.sonatype.nexus.DefaultNexus.startService(DefaultNexus.java:682) jvm 1 | at org.sonatype.nexus.DefaultNexus.start(DefaultNexus.java:647) [/sourcecode] ... Oh, Mist. Stellen Sie die Konfiguration für Nexus 1.9 wieder her und starten Sie diese. Ich befinde mich jetzt in einer stabilen, aber nutzlosen Situation, in der Nexus 1.9 läuft und meine Maven 2-Builds fehlschlagen. Es ist 19:20 Uhr, ich werde morgen wiederkommen.

Versuchte Korrektur: -Dmaven.metadata.legacy=true

Bei der Recherche zu diesem Thema bin ich auf NEXUS-3806 gestoßen, in dem eine maven.metadata.legacy Systemeigenschaft erwähnt wird. Das sieht hoffnungsvoll aus, wenn man davon ausgeht, dass Nexus und Maven 2/3 Teile ihrer Codebasis gemeinsam nutzen. Ich habe Nexus heruntergefahren und -Dmaven.metadata.legacy=true zur wrapper.conf hinzugefügt. Neustart von Nexus, Neuaufbau der Metadaten für mein Snapshots-Repository. Daumen drücken......aber kein Glück, die Metadaten sind immer noch im Maven 3 Format. Es ist jetzt Mittag des nächsten Tages und meine Maven-Builds sind immer noch fehlerhaft. Während ich dies schreibe, stelle ich fest, dass ich nicht versucht habe, die vorhandenen Metadaten-Dateien zu löschen, bevor ich den Befehl Rebuild Metadata ausgeführt habe. Wenn Sie also in der Lage sind, dies zu überprüfen, dann tun Sie es bitte und hinterlassen Sie eine Notiz in den Kommentaren.

Versuchte Korrektur: Maven 2 soll das Maven 3-Metadatenformat verstehen

Ich glaube, MNG-4452 hat die Änderung des Metadaten-XML-Formats veranlasst, die auf maven-artifact Version 3.0 angewendet wurde. Ich weiß genug über die Interna von Maven aus früheren Fehlersuchen, um die Hoffnung auf eine Rückportierung auf Maven 2 schnell aufzugeben.

Zurück zum Funktionieren von Nexus 1.8.0.1

Ich habe beschlossen, dort weiterzumachen, wo ich gestern Abend aufgehört habe. Ich beendete Nexus, benannte mein sonatype-work-Verzeichnis um und startete Nexus neu, um eine Neuinstallation zu emulieren. So hatte ich ein frisches, neu erstelltes sonatype-work-Verzeichnis, das ich mit meinem bestehenden vergleichen konnte. Schließlich konnte ich die Ursache für den fehlgeschlagenen Start auf die Datei security-configuration.xml zurückführen. Hier ist die Originaldatei: [sourcecode language="xml"] <?xml version="1.0"?> <Sicherheits-Konfiguration> <Version>2.0.3</version> <aktiviert>true</enabled> <anonymousAccessEnabled>true</anonymousAccessEnabled> <anonymousBenutzername><!-- versteckt --></anonymousUsername> <anonymousPassword><!-- versteckt --></anonymousPassword> <Reiche> <realm>NexusLdapAuthenticationRealm</realm> <realm>XmlAuthenticatingRealm</realm> <realm>XmlAuthorizingRealm</realm> </realms> <securityManager>web</securityManager> </security-configuration> [/sourcecode] Das Element <securityManager> und NexusLdapAuthenticationRealm waren in der neuen Konfiguration nicht vorhanden. Ich habe mein ursprüngliches sonatype-work-Verzeichnis wiederhergestellt und diese beiden Zeilen entfernt. Nexus 1.8.0.1 startet jetzt erfolgreich! Es ist jetzt drei Uhr nachmittags, ich brauchte jetzt eine gute Nachricht. Ich ging in die Weboberfläche und aktivierte LDAP auf der Seite Administration/Server wieder. Dadurch wurde der NexusLdapAuthenticationRealm in meiner XML-Datei wiederhergestellt, was bedeutet, dass das Element <securityManager> den Start meines heruntergestuften Nexus verhindert hat. Die allererste Nexus-Version, die ich auf unserem Build-Server installiert habe, war 1.7.1. Das securityManager-Element muss ein Überbleibsel dieser Version sein, auch wenn das nicht erklärt, warum es den Start von Nexus vorher nicht verhindert hat.

Hat das meine Maven-Builds repariert?

Nicht auf den ersten Blick. Die Aufgabe Rebuild Metadata in Nexus 1.8.0.1 überspringt alle vorhandenen Metadaten-Dateien. Nachdem ich das herausgefunden hatte, löschte ich diese auf dem Dateisystem mit einem schnellen find /home/maven/sonatype-work/nexus/storage/snapshots -name "maven-metadata.xm*" -delete. Nach einem weiteren Rebuild Metadata habe ich endlich meine Repository-Metadaten im Maven 2-Format. Hat das meine Maven-Builds repariert? Nein, denn die Metadaten-Dateien im Stil von Maven 3 befanden sich immer noch in meinem lokalen Repository. Dies ist die Zielgerade. Wenn ich sie mit einem weiteren schnellen Find-Befehl aus dem lokalen Repository entferne, funktionieren meine Maven 2-Builds wieder.

Eine gewisse Befriedigung erhalten

[sourcecode language="text"] rm -rf nexus-oss-webapp-1.9 [/sourcecode] Leck mich am Arsch, du hohlköpfiger Futtertrogauswischer! Ich furze in Ihre allgemeine Richtung*!

Gelernte Lektionen

Mit Maven 3 ist die Installation von Sonatype ein gefährliches Unterfangen, wenn Sie noch mit Maven 2 arbeiten(Update: eine veraltete Version). Nexus 1.9 hat sich als inkompatibel mit Maven 2 erwiesen, sicher unbeabsichtigt. Es ist einfacher, Nexus nicht zu aktualisieren, als ein Downgrade vorzunehmen. Ich weigere mich, eine DTAP-Kette für meine Entwicklungsunterstützungs-Tools zu verwenden, also werde ich von nun an ganz darauf verzichten, Nexus zu aktualisieren.Ich werde Jenkins verwenden, um meinen Zwang, alles auf dem neuesten Stand zu halten, zu befriedigen ;)