Tipps für einen internen Maven Repository beibehalten?

Question

Ich bin daran interessiert, eine Maven 2 Repository für meine Organisation aufrechtzuerhalten. Was sind die einige der Zeiger und Fallen, die helfen würde.

Was sind Richtlinien für Benutzer zu folgen, wenn Standards Einrichtung zum Download oder veröffentlichen ihre eigenen Artefakte in das Repository, wenn ihr Code zu veröffentlichen? Welche Arten von Governance / Regeln haben Sie in Ort für diese Art der Sache? Was sind Sie es in Ihrem Entwicklerleitfaden / Dokumentation?

UPDATE : Wir haben Nexus stand auf und haben damit sehr zufrieden - die meisten von Sal Richtlinien gefolgt und haben keine Probleme hatte. Darüber hinaus haben wir deploy Zugang beschränkt und automatisierte Build / Bereitstellung von Snapshot-Artefakte durch einen Hudson CI-Server. Hudson können alle der Upstream / Downstream-Projekt Abhängigkeiten analysieren, so dass, wenn eine Zusammenstellung Problem, Testfehler oder eine andere Verletzung der Build verursacht zu brechen, wird kein Einsatz kommen. Seien Sie müde in Maven2 / Maven3 Snapshot-Installationen zu tun, da die Metadaten zwischen den beiden Versionen geändert hat. Die „Hudson nur“ Snapshot-Bereitstellungsstrategie wird dies abzumildern. Wir verwenden nicht die Release-Plugin, haben aber einige Sanitär um die Versionen geschrieben Plugin wenn gehen, um einen Schnappschuss zu bewegen zu lösen. Wir verwenden auch m2eclipse und es scheint, mit Nexus sehr gut zu funktionieren, wie aus der Einstellungsdatei es Nexus sehen kann und weiß, zu indizieren Artefakt Informationen für die Suche von dort. (Obwohl ich hatte einige diese Einstellungen zu optimieren, es haben voll Index unsere internen Schnappschüsse.) Ich auch Sie eine Quelle Glas mit Ihrem Artefakte als Standardverfahren einsetzen würde empfehlen, wenn Sie daran interessiert sind diese. Wir konfigurieren, dass in einem Super POM.

UPDATE2 : Ich habe über

War es hilfreich?

einreichen

Lösung

Ich würde empfehlen, ein Nexus-Server mit mindestens vier Repositories einzurichten. Ich würde artifactory nicht empfehlen. Die kostenlose Version von Nexus ist ein Entwicklerteam von weniger als 20 in weniger als drei Gruppen völlig in Ordnung. Wenn Sie mehr als das Benutzer haben, tun sich selbst einen Gefallen und zahlen für das Sonatype Release. Die LDAP-Integration zahlt sich aus.

1. Interne Veröffentlichung
2. Interne Snapshot
3. Interner 3rd Party für Code im Hause verwendet, die von außen kommen, oder für gebilligt 3rd-Party-Versionen. Setzen Sie den JDBC-Treiber, javax. * Sachen und Sachen von Kunden und Partnern hier.
4. Externe Proxies gemeinsame Proxy für alle üblichen Quellen wie m2, etc Codehaus

Konfigurieren Nexus folgendes für die interne repos zu tun

1. Löschen Sie alte Snapshots in regelmäßigen Abständen
2. Löschen von Schnappschüssen auf Release
3. Index-Dateien erstellen. Dies beschleunigt die lokale baut auch

hat eine gemeinsame settings.xml-Datei, die diese vier und nur diese vier Quellen verwendet. Wenn Sie darüber hinaus anpassen müssen versuchen, einen gemeinsamen Teil zu halten der Einstellungen Datei und verwenden Profile für die Unterschiede. lassen Sie sich nicht Ihre Kunden rollen nur ihre eigenen Einstellungen oder Sie werden mit dem Code am Ende, die auf einer Maschine baut, aber nicht auf einer anderen Maschine.

eine gemeinsame Proxy für Ihre Kunden. In Nexus, können Sie eine Reihe von Proxies zu den gemeinsamen Maven Quellen (Apache, JBoss, Codehaus) hinzufügen und haben einen einzigen Proxy zu den internen Kunden ausgesetzt . Dies macht das Hinzufügen und Quellen von Ihren Kunden viel leichter zu entfernen.

Interne und 3rd-Party-Artefakte nicht im gleichen Repository mischen. Nexus ermöglicht es Ihnen, Gläser mit einem internen Repository über einen Web-GUI hinzuzufügen. Ich empfehle dies als die Art und Weise Ihre JDBC-Treiber und anderen externen Code auf 3rd-Party-Zusatz. Die Benutzeroberfläche ist sehr schön zu verwenden, wenn im Vergleich zu den meisten Enterprise-Software .

Definieren einer gemeinsamen Mutter POM , die den internen Snapshot und Release repos über die distribution Tag definiert. Ich weiß, dass viele Leute sagen, dies nicht zu tun. Und während ich frei zugeben, dass es alle Arten von Problemen mit diesem zu tun, klappt es in Ordnung, wenn die Kunden nur Releases und Snapshots bauen auf einen einzigen internen Repository bereitgestellt werden.

Wenn Sie eine vorhandene Fehl verwaltet Maven-Repository , erstellen Sie eine fünfte repos namens Vermächtnis und setzen Sie die ganze repos dort. Stellen Sie einen Cron-Task bis zu alten Dateien aus Legacy zu löschen, nachdem sie ein Jahr alt sind. Das gibt jedem ein Jahr weg von ihr zu bewegen und ihre poms zu aktualisieren.

Stellen Sie eine einfache Namenskonvention für die interne Artefakte bleiben. Ich ziehe GroupID von Department.Function.Project und eine ArtifactId für das component . Für die internen Repositories, com / org / net und der Firmenname ist wahrscheinlich irrelevant. Und falsch, wenn das Unternehmen ändert seinen Namen. Es ist viel weniger wahrscheinlich, dass der Verkauf, Buchhaltung oder Inventar Abteilung wird umbenannt.

Answer 1

Ich würde empfehlen, ein Nexus-Server mit mindestens vier Repositories einzurichten. Ich würde artifactory nicht empfehlen. Die kostenlose Version von Nexus ist ein Entwicklerteam von weniger als 20 in weniger als drei Gruppen völlig in Ordnung. Wenn Sie mehr als das Benutzer haben, tun sich selbst einen Gefallen und zahlen für das Sonatype Release. Die LDAP-Integration zahlt sich aus.

1. Interne Veröffentlichung
2. Interne Snapshot
3. Interner 3rd Party für Code im Hause verwendet, die von außen kommen, oder für gebilligt 3rd-Party-Versionen. Setzen Sie den JDBC-Treiber, javax. * Sachen und Sachen von Kunden und Partnern hier.
4. Externe Proxies gemeinsame Proxy für alle üblichen Quellen wie m2, etc Codehaus

Konfigurieren Nexus folgendes für die interne repos zu tun

1. Löschen Sie alte Snapshots in regelmäßigen Abständen
2. Löschen von Schnappschüssen auf Release
3. Index-Dateien erstellen. Dies beschleunigt die lokale baut auch

hat eine gemeinsame settings.xml-Datei, die diese vier und nur diese vier Quellen verwendet. Wenn Sie darüber hinaus anpassen müssen versuchen, einen gemeinsamen Teil zu halten der Einstellungen Datei und verwenden Profile für die Unterschiede. lassen Sie sich nicht Ihre Kunden rollen nur ihre eigenen Einstellungen oder Sie werden mit dem Code am Ende, die auf einer Maschine baut, aber nicht auf einer anderen Maschine.

eine gemeinsame Proxy für Ihre Kunden. In Nexus, können Sie eine Reihe von Proxies zu den gemeinsamen Maven Quellen (Apache, JBoss, Codehaus) hinzufügen und haben einen einzigen Proxy zu den internen Kunden ausgesetzt . Dies macht das Hinzufügen und Quellen von Ihren Kunden viel leichter zu entfernen.

Interne und 3rd-Party-Artefakte nicht im gleichen Repository mischen. Nexus ermöglicht es Ihnen, Gläser mit einem internen Repository über einen Web-GUI hinzuzufügen. Ich empfehle dies als die Art und Weise Ihre JDBC-Treiber und anderen externen Code auf 3rd-Party-Zusatz. Die Benutzeroberfläche ist sehr schön zu verwenden, wenn im Vergleich zu den meisten Enterprise-Software .

Definieren einer gemeinsamen Mutter POM , die den internen Snapshot und Release repos über die distribution Tag definiert. Ich weiß, dass viele Leute sagen, dies nicht zu tun. Und während ich frei zugeben, dass es alle Arten von Problemen mit diesem zu tun, klappt es in Ordnung, wenn die Kunden nur Releases und Snapshots bauen auf einen einzigen internen Repository bereitgestellt werden.

Wenn Sie eine vorhandene Fehl verwaltet Maven-Repository , erstellen Sie eine fünfte repos namens Vermächtnis und setzen Sie die ganze repos dort. Stellen Sie einen Cron-Task bis zu alten Dateien aus Legacy zu löschen, nachdem sie ein Jahr alt sind. Das gibt jedem ein Jahr weg von ihr zu bewegen und ihre poms zu aktualisieren.

Stellen Sie eine einfache Namenskonvention für die interne Artefakte bleiben. Ich ziehe GroupID von Department.Function.Project und eine ArtifactId für das component . Für die internen Repositories, com / org / net und der Firmenname ist wahrscheinlich irrelevant. Und falsch, wenn das Unternehmen ändert seinen Namen. Es ist viel weniger wahrscheinlich, dass der Verkauf, Buchhaltung oder Inventar Abteilung wird umbenannt.

Answer 2

Auf jeden Fall benutzen Nexus . : P

Ich habe sowohl Nexus und Artifactory verwendet. Die Schnittstelle für Nexus ist viel robuster, es viel mehr konfigurierbar ist, und natürlich geschrieben von Sonatype , das repesents gut so ziemlich alles Maven.

Dass gesagt wird, Artifactory ist anständig und praktikabel.

• Eine Überprüfung der Nexus vs. Artifactory
• Oh my! Natürlich ist hier eine SO quesiton über die Sache.
• Sonatype hat ein Feature Vergleich
• JFrog (Hersteller von Artifactory) hat einen Funktionsvergleich

Answer 3

Verwenden Sie Artifactory .

Answer 4

Ich bin mit mir selbst Artifactory und lieben die Benutzeroberfläche und die einfache Implementierung / Wartung. Das heißt, ich habe noch nie Nexus verwendet, und kann man nicht wirklich helfen, mit einem richtigen Feature-Vergleich.

Hier sind einige Dinge aus der Spitze von meinem Kopf, die ich mag wirklich über Artifactory (bedenken Sie Nexus haben können diese Funktionen auch):

1. Nizza Web-2.0-Schnittstelle.
2. Die Möglichkeit, Ihre lokale Maven-Repository zu importieren Sie begannen um Hilfe zu holen.
3. Einfache Integration mit bestehendem LDAP-Server für die Sicherheit (Ich bin ein großer Fan von einem einzigen Repository-Anmeldeinformationen zum Speichern).

Da gibt es wirklich nur zwei große Maven Repository Implementierung gibt, wenn Sie wirklich sicherstellen möchten Sie die richtige Wahl getroffen haben, würde ich beide aus, und entscheiden Sie selbst, empfehlen daher, die Ihnen besser gefällt.

Answer 5

Vielleicht ist dies offensichtlich, aber für die Reproduzierbarkeit, Entwickler sollten nie Artefakte überschreiben, sollten sie neue Versionen sein.

Dies gilt auch für Upstream-Repositories. Wenn Sie Apache-Commons-Version 1.2.3 herunterladen, sollten Sie es wirklich nie wieder herunterladen. Fixes kommt aus letzteren Versionen, nicht angewendet bestehenden Versionen.

Answer 6

Etwas anderes zu berücksichtigen:

http://archiva.apache.org/

Answer 7

Wie die Original Frage (technische Aspekte zu berücksichtigen, wenn eine M2-Repository Konstruktion), würde ich empfehlen, die Nur-Lese-Benutzer für das Surfen im Repository und administrative Benutzer pro Administrator (die sagten: ein Lese -nur Benutzer für alle jene Benutzer, die keine Administratoren sind). Außerdem würde ich empfehlen, regelmäßig Backup-Images zu erzeugen (einmal täglich vielleicht?). Sehr wichtig, wenn sowohl das Repository ist groß oder Sie Ihre eigenen Artefakte von Zeit zu Zeit installieren.

Last, but not least, wenn neue Remote-Repositories hinzufügen, Sie Aufnahme müssen hinzufügen / Ausschluss-Filter so ein Artefakt-Lookup im Repository würde schneller durchgeführt werden.

Es gibt viele anderen Aspekte zu berücksichtigen, aber diese sind die führenden Fragen, die ich erlebt habe, während ein Maven internen Repository verwalten.

Für das Protokoll, ich bin mit beiden Nexus und Artifactory; Ich kann klar sagen, dass, während Nexus ist sehr einfach und wirksam ist (obwohl ich manchmal Probleme mit der Installation auf Ubuntu habe), seine kostenlose Version nicht mit Artifactory-Community (kostenlos) Ausgabe konkurrieren kann. Ohne Artifactory ehrfürchtigen Web-2-UI, die wichtigsten Funktionen, wie zum Beispiel Sicherheitsmanagement, regelmäßige Backups und Fragen der Zugänglichkeit sind weit über die von Nexus.