Bündelung eine Nicht-Open-Source-Abhängigkeit mit Maven

Angenommen, ich habe zwei Java-Projekte in Maven/Eclipse-:Bündelung eine Nicht-Open-Source-Abhängigkeit mit Maven

Ein Open-Source-Anwendung in GitHub
Eine kleine private Bibliothek mit Hilfsfunktionen, die ist nicht Open Source (die ich aber die Rechte haben zu verändern, zu bauen und in kompilierter Form zB als .jar-Datei verteilen)

ich es für andere machen möchten möglich zu bauen, zu modifizieren und Führen Sie die Anwendung aus (und zurück zum Open-Source-Projekt beitragen, wenn sie möchten!), aber das bedeutet, dass sie auch die Bibliothek als Abhängigkeit benötigen.

Ich möchte die Dinge einfach halten, so dass Builds für mich und die Benutzer der Anwendung einfach sind.

Was ist der praktischste Weg, um dies zu erreichen?

Quelle

2012-06-27 mikera

Stellen Sie Ihr eigenes Maven-Repository auf GitHub bereit, um die geschlossene Quellbibliothek zu verteilen, die Sie weiterverbreiten dürfen, und verweisen Sie auf Ihr Projekt (pom.xml).

http://cemerick.com/2010/08/24/hosting-maven-repos-on-github gibt eine nette Einführung in die Einrichtung eines Repository auf GitHub. Sie sollten sich der Vorbehalte eines solchen Mikroarchivs bewusst sein, das ebenfalls in diesem Beitrag erwähnt wird.

Quelle

2012-06-27 11:25:49 stefanglase

+1 Dies ist der bessere Weg, es zu tun! –

Gibt es eine Möglichkeit, zu sehen, wer oder wie viele Leute die Artefakte von Github herunterladen? Es sieht so aus, als ob github nur Statistiken sammelt, wenn du das Repo klonst. – cosbor11

Wenn mit Maven arbeiten wird empfohlen, ein Maven-Repository-Manager wie Nexus zu verwenden und Ihre Einstellungsdatei konfigurieren, wie hier beschrieben:

https://help.sonatype.com/display/NXRM3/Maven+Repositories#MavenRepositories-ConfiguringApacheMaven

In Ihrer Situation hat dies den zusätzlichen Vorteil, dass Sie nutzen könnten der Maven Repository Manager, um private Artefakte zu hosten.

Quelle

2012-06-27 11:20:33 Puce

hmmm aber in diesem Fall möchte ich öffentliche Open-Source-Benutzer in der Lage sein, das Artefakt zu verwenden (idealerweise ohne ihre Einstellungen zu hacken). Jeder Weg, das zu tun? – mikera

Sie können nie sicher sein, dass jemand Ihr Glas nicht missbrauchen wird (es zu dekompilieren) – ant

z. Für Nexus müssen Sie die öffentliche Gruppe für alle zugänglich machen (ich denke, das ist der Standard, wenn Sie eine öffentliche IP-Adresse/Domäne verwenden) und sicherstellen, dass Ihr Hosting-Repository mit Ihrer privaten Bibliothek in dieser öffentlichen Gruppe ist. Andere Benutzer können dann Ihr Repository in ihrem eigenen Maven Repository Manager verwalten. – Puce

Eine wirklich einfache Lösung wäre, Ihre private Bibliothek in Ihr Projekt (z. B. <project>/lib/library-1.0.jar) zu legen und es als system Abhängigkeit aufzunehmen. Sie können es in Ihrem Pom wie einschließen.

<dependencies> 
    <dependency> 
     <groupId>my.private</groupId> 
     <artifactId>library</artifactId> 
     <version>1.0</version> 
     <scope>system</scope> 
     <systemPath>${project.basedir}/lib/library-1.0.jar</systemPath> 
    </dependency> 
    </dependencies>

Vorsicht: Eine Systemabhängigkeit transitiv ist nicht!

Aus der Dokumentation

Dieser Bereich ist ähnlich, außer vorausgesetzt, dass Sie die JAR schaffen, die es explizit enthält. Das Artefakt ist immer verfügbar und wird nicht in einem Repository nachgeschlagen.

Quelle

2012-06-27 11:48:49 FrVaBe

Danke, sehr nützlich. Gibt es eine gute Möglichkeit, die Bibliothek Jar-Datei automatisch zu aktualisieren, wenn ich das Bibliotheksprojekt neu erstellen? – mikera

Dies ist eine einfache Lösung, aber klar, nicht besser, wegen der Transitivitätsprobleme. Aber es erfüllt die Anfrage ... –

@mikera Ich weiß nicht, wie das Bibliotheksupdate zu vereinfachen. Wenn Ihre Bibliothek in einer neuen Version veröffentlicht wird, müssen Sie etwas tun - sogar mit dem Repository-Ansatz. Sie müssen die Versionsnummer Ihrer Abhängigkeit in Ihrer pom.xml aktualisieren (vorausgesetzt, Sie verwenden keine Versionsbereiche, die eine Erstellung unreproduzierbar machen). – FrVaBe

Bündelung eine Nicht-Open-Source-Abhängigkeit mit Maven

Antwort

Verwandte Themen