Repository manager

Hi,

ich bin auf der suche nach einem für kommerzielle Nutzung kostenfreien Repository-Manager.
Die Anforderungen sind derzeit noch sehr moderat (das lokale Maven-Repo reicht eigentlich noch aus), sodass es erstmal konstenfrei sein soll. Ich möchte lediglich selbst gebaute Artefakte intern deployen, sodass ich sie sauber als Dependency zu einem anderen Projekt hinzufügen kann.
Einer (zugegebenermaßen sehr kurzen) Googlesuche nach käme Nexus OSS in Frage.
Welche Optionen gibt es noch? Gibt es bei einer Option signifikante Vorteile?

Artifactory wäre eine Alternative, aber mit Nexus macht man nix falsch

Artifactory fiel mir auch zuerst ein, da hatte ich aber scheinbar nicht richtig gelesen, denn ich dachte, dass artifactory nur in einer kostenpflichtigen Version erhältlich sei.
Im 1-Minute-Tutorial wird die Integration mit TeamCity erwähnt. Wenn Nexus nicht integriert ist, wäre das ein Argument für artifactory.

Hi @cmrudolph :slight_smile:

Der Unregistered Post war von mir… unterwegs und so.

Weder Teamcity noch ein anderer CI muss eine Integration mit dem Repository Manager haben bei Maven Projekten, denn Maven macht das alles selber :wink:

Es gibt ein Plugin fuer Teamcity und Artifactory:
https://www.jfrog.com/confluence/display/RTF/TeamCity+Artifactory+Plug-in
https://www.jfrog.com/confluence/download/attachments/25067936/TCBuildStepConfig.png?version=1&modificationDate=1416216916000&api=v2

Uncheck if you do not wish to depoloy Maven artifacts from the plugin (a more efficient alternative to Mavens own deploy goal)

Was daran genau “more efficient” sein soll weiss ich nicht, kenne ja TeamCity nicht.
Aber es sollte klar sein, das so etwas optional ist, nicht zwingend, denn Maven kann das wie gesagt auch ganz alleine :wink:

In der POM gibt es genau dafuer das Element, das sollte sowieso vorhanden sein, denn in welches Repo ein Projekt seine Artifakte steckt ist schon Teil des Projektes.

Nexus hat IMHO den Vorteil, dass man dafuer keine MySQL DB braucht wie beim Artifactory, alles liegt im Dateisystem, eine SW Komponente weniger (kein MySQL) benoetigt.
Dafuer kann Artifactyory aber wohl mehr Metainformationenen, auch selbstdefinierte, speichern.

Ob mit/ohne Plugin bzw. Nexus oder Artifactory muss erst mal egal sein koennen, willst in deinem Build keine Spezifika der Implementierungen nutzen, sondern alles per Maven Standard erstmal.

Was IMHO wichtiger ist und groesseren Einfluss haben wird, ist, ob du SNAPSHOTs auch in den Repo Manager stecken willst.
SNAPSHOTs machen Dinge etwas komplexer was Reproduzierbarkeit und das verhalten von Maven betreffen.

  1. SNAPSHOT Dependencies zu anderen Projekten koennen deinen Build fragil machen, eine Aenderung im SNAPSHOT, schon kann dein Projekt brechen ohne dass du eine einzige Zeile geaendert hast.
  2. Maven wird alle 24 Stunden versuchen einen neueren SNAPSHOT runterzuladen und den alten zu ersetzen, vollautomatisch, ohne dass du das bewilligen musst (updatePolicy), wenn du die Maven Log Ausgabe nicht genau liest, verpasst du das vielleicht, und du denkst dir nur “gestern ging noch alles…???”
  3. Da SNAPSHOTs nicht repropduzierbar sind, kannst du dein Projekt nicht releasen solange SNAPSHOT abhaengigkeiten auf andere Projekte bestehen, das Release Plugin prueft das, Released du manuell kann das aus versehen uebersehen werden…

Mein Tipp:

  1. Wenn dein Projekt eine SNAPSHOT Abhaengigkeit zu einem anderen Projekt hat dass du nicht releasen kannst, lade das Ding mit einer eindeutigen Release Versionsnummer in das 3rd Party Repo deines Repo Managers, so ist dein Build reproduzierbar.
  2. SNAPSHOTs muessen oft geprueft werden ob es nicht einen neueren gibt, das macht den Build langsam, deswegen und weil mit SNAPSHOT Abhaengigkeiten dein Build nicht reproduzierbar ist: Keine externen SNAPSHOT repos in deine Repo Manager eintragen! Wenn du experimentieren willst kannst du ja temporaer deinen Repo Manager aushaengen und direkt ins Netz gehen.
  3. Deine/eure Projekte muessen mit 1-2 Klicks released werden koennen, das M2 Jenkins Plugin macht das zB., sowas gibt es bestimmt auch fuer die anderen CI Server wie TeamCity und Bamboo, von letzterem wusste ich das mal.

Ansonsten:
In der settings.xml deinen Repo Manager als Mirror eintragen, so dass im Normalfall alles nur ueber deinen Repo Manager aufgeloest wird, bei Kommerzieller SW auch keine Repos in die POMs eintragen, stattdessen eben in der settings.xml den Mirror auf den eigenen Repo Manager eintragen.
D.h. auch dass alle Repo die der Build braucht im Repo Manager eingetragen sind.

Bei Fragen einfach Fragen :slight_smile:

Erstmal herzlichen Dank für eine derart ausführliche Antwort!
Bei dem Projekt, in dem der Wunsch nach einem Repository Manager aufkam, verwende ich gradle. Daher versuche ich meinen Beitrag konzeptuell zu halten.
Der Wunsch kam deshalb auf, weil ich ein Artefakt erstellen muss / möchte, das ein anderes Projekt erweitert. Konkret geht es um eine winzige Erweiterung der Templateengine Thymeleaf, die unabhängig vom Hauptprojekt ist. Deshalb möchte ich sie nicht in dem (multiproject-)build einfügen, auch wenn es dort nur eine “interne” Abhängigkeit wäre.
Denn ich kann mir vorstellen, dass diese Erweiterung auch in anderen Projekten relevant sein könnte.

Das Plugin für artifactory / TeamCity habe ich gestern auch schon gefunden und installiert. Einen echten Mehrwert gegenüber dem gradle-Plugin habe ich nicht direkt gesehen. Prinzipiell unterstützt gradle natürlich auch das “Standarddeployment” von maven (siehe hier).
Allerdings, und jetzt bin ich wieder konzeptuell, stellt sich mir die Frage, wo die richtige Stelle im Build ist, um die Artefakte zu deployen. Gehört das in die Build-Konfiguration oder in den CI-Server? Ich hätte jetzt nämlich eigentlich gedacht, dass es besser in die Konfiguration vom CI-Server passen würde. Das hält das Buildfile frei von Infrastruktur (keine fest hinterlegten Server). Die Effizienz beim Deployment halte ich vorerst für sekundär.

Der Vorteil bei Nexus keine MySQL-Datenbank zu benötigen kommt bei mir nicht wirklich zum Tragen, weil ich für den CI-Server, für das Projekt selbst und auch mehrere andere mehr oder minder große Projekte einen MySQL-Server administriere. Ich war bei der Installation sogar ausnahmsweise mal vorausschauend genug, um den MySQL-Connector schon vorher in das richtige Verzeichnis zu kopieren und die manuelle Konfiguration gem. Dokumentation vorzunehmen :wink:

Deine Ausführungen zu SNAPSHOTs sind plausibel und ich verwende bisher auch keine. (Ok, zugegebenermaßen gerade in diesem Moment verwende ich einen Spring 4.2 Snapshot, weil dort ein neues Feature implementiert wurde, das ich mir in einem JIRA Issue “gewünscht” hatte. Das ist aber nur testweise, bis es in zwei (?) Wochen den ersten RC gibt.)

Bei selbst deployten SNAPSHOTs ist die Problematik denke ich mal deutlich weniger kritisch - dort habe ich ja alles selbst in der Hand. Sobald es einen stabilen Zustand gibt, kann ich dann ja intern auch releasen.

Zum Thema “frei von Infrastruktur” hatte ich gestern auch noch die Überlegungen, ob ich den artifactory überhaupt als Proxy nutzen soll oder ob ich dort nur die selbst deployten Artefakte zwischenlagere. Du hast im Abschnitt ab “Ansonsten:” geschrieben, dass man das aber genau nicht machen soll.
Der Grund dafür ist wahrscheinlich, dass man dadurch alles unter eigener Kontrolle hat und somit der Build nicht brechen kann, wenn ein fremdes Repo mal nicht erreichbar ist.

Bei meinem Hauptprojekt ist es so, dass ich vielleicht wirklich den eigenen Repo Manager als einziges Repository eintragen kann. Bei der Erweiterung von Thymeleaf hingegen könnte ich mir vorstellen, sie open source zur Verfügung zu stellen. Da wäre es dann wohl sinnvoll, das Deployment so zu konfigurieren, dass die Artefakte in einem öffentlichen Repo landen und die eigenen Abhängigkeiten aus maven central geholt werden, oder?

Wie gesagt, bestimmte Dinge gehoeren zum Projekt, u.a. wo das SCM zu finden ist, die Projektseite, aber auch in welche Repos deployed wird, das gehoert bei Maven in die POM.

Das ist ja auch ok, mal was ausprobieren hiesst ja nicht gleich Tuer & Tor fuer alles SNAPSHOT Repos zu oeffnen, kann man zB. bei Maven in der settings.xml machen.
Kenne mich nicht wirklich mit Gradle auch, was ist da da Equivanlent fuer settings.xml und Mirror Einstellungen?

Das wird erst problematisch, wenn andere Teams/Projekte deine SNAPSHOTs als Dependencies nutzen.
Wenn du deine SNAPSOTs nicht brauchst, solltest du IMHO auch keine Deployen.

[quote=cmrudolph;116314]Zum Thema “frei von Infrastruktur” hatte ich gestern auch noch die Überlegungen, ob ich den artifactory überhaupt als Proxy nutzen soll oder ob ich dort nur die selbst deployten Artefakte zwischenlagere. Du hast im Abschnitt ab “Ansonsten:” geschrieben, dass man das aber genau nicht machen soll.
Der Grund dafür ist wahrscheinlich, dass man dadurch alles unter eigener Kontrolle hat und somit der Build nicht brechen kann, wenn ein fremdes Repo mal nicht erreichbar ist.[/quote]
Ja, am besten alles ueber den Repo Manager, die Caches niemals loeschen, dann kann dir egal sein wenn zB. das JBoss Repo wieder mal umzieht, deine Projekte brechen nicht.
Dazu eine Repo Gruppe in deinem Repo Manager anlegen, das kannst du dann aussuchen welche Repos abgefragt werden und in welcher Reihenfolge,

Deine POMs blieben so frei von externen Repo URLs, dein Repo Manager kuemmert sich dann darum.
Der Normalfall fuer kommerziielle SW.

Bei OSS ist alles anders :slight_smile:
Alle Repos muessen da in die POM, weil die anderen wohl nicht deinen privaten Repo Manager nutzen sollen/duerfen.
Das Deployen nach Maven Central ist eine kleine Wissenschaft fuer sich, einfach hinschieben ist da nicht.
Da wird genau geprueft ob alle Dinge in der POM (muss erzeugt werden dafuer) auch vorhanden sind (Projekt URL, SCM, distributionManagement, etc. pp.), fehlt was, kann nicht auf Central Deployed werden…

Wie du siehst, soll die POM nicht “frei von infrastruktur” sein, sondern genau diese Infos enthalten.

Ich bin zwar auch kein gradle-Profi, aber dort würde man wohl mit einem nutzerspezifischen Initscript arbeiten, in dem man einfach das Repo hinzufügt, in dem der Snapshot liegt.

Hört sich nach 'nem Plan an :wink: Ich werd mein Hauptprojekt mal darauf umstellen.

Das ist ja zum Glück (noch) nicht dar Plan. So kann ich das dann schrittweise angehen.
Die pom.xml für das Artefakt erzeugt gradle übrigens mit dem maven-Plugin automatisch.

Das muss ich jetzt alles erst einmal konfigurieren und sacken lassen.
Der Repo-Manager wird übrigens so auch zu einem integralen Bestandteil der Anwendung, daher muss er bei der Backupstrategie besser berücksichtigt werden.

[ot]Ich glaube, mittlerweile ist mein Toolstack komplett:
IDE: IntelliJ IDEA
VCS: STASH
Bugtracker: JIRA (mit Agile-Plugin)
CI-Server: TeamCity
Repo-Manager: artifactory
Und alle hübsch miteinander integriert :wink: So macht Sw-Entwicklung Spaß![/ot]