Wir haben mehrere Produkte, die viel geteilten Code haben und die mehrere Versionen beibehalten müssen.
Um dies zu handhaben, verwenden wir viele Eclipse-Projekte, einige enthalten Bibliotheks-Jars, und einige enthalten geteilten Quellcode (in mehreren Projekten, um einen riesigen Haufen mit zahlreichen Abhängigkeiten zu vermeiden, während alles von Grund auf neu kompiliert werden kann, um diese Quelle sicherzustellen) und Binärdateien sind konsistent). Wir verwalten diese mit projectSet.psf, da diese alle Projekte direkt aus CVS herausziehen und einen vollständig vorbereiteten Arbeitsbereich hinterlassen können. Wir machen keine Ameisen-Builds direkt oder benutzen Maven.
Wir wollen nun alle diese Projekte und ihre verschiedenen Versionen in ein Continous Integration Tool einbauen können - ich mag Hudson, aber das ist nur eine Frage des Geschmacks - was im Wesentlichen bedeutet, dass wir einen automatischen Weg zum Auschecken brauchen die Projekte in einen neuen Arbeitsbereich und kompilieren die Quellordner wie in den Projektdateien in jedem Projekt beschrieben. Hudson bietet keinen solchen Ansatz, um ein Projekt zu erstellen, also habe ich darüber nachgedacht, wie der beste Weg dazu aussehen könnte.
Ideen waren
Ich würde wirklich gerne von den Erfahrungen anderer Leute hören, damit ich entscheiden kann, wie ich das angehen soll.
Bearbeiten: Eine andere Option könnte ein CI sein, das sich besser mit Eclipse-Projekten und / oder Projektsätzen auskennt. Wir sind nicht religiös - es geht nur darum, Dinge in Gang zu bringen, ohne alles selber machen zu müssen. Wäre Cruise Control vielleicht eine bessere Option? Andere?
Bearbeiten: Gefunden, dass ant4eclipse eine "Team Project Set" -Funktion hat. Ссылка
Bearbeiten: Verwendet die Erweiterungen ant4eclipse und ant-contrib ant, um einen vollständigen Arbeitsbereich als sjgned runnable jar-Datei zu erstellen, ähnlich der Runnable Jar-Funktion in Eclipse 3.5M6. Ich bin immer noch abhängig von Eclipse, um den ersten leeren Arbeitsbereich zu erstellen und das ProjectSet zu extrahieren, das ist die nächste Hürde.
Edit: Beendet mit einer Doppelkonfiguration, nämlich dass Hudson die gleichen Module wie in der Datei ProjectSet.pdf von CVS (die das gleiche Tag haben muss) in der Liste findet, sodass sie nebeneinander liegen. Dann funktioniert ant4eclipse gut mit der im Hauptmodul eingebetteten Datei projectSet.psf. Vorbehalt: Die Modulliste in Hudson muss manuell aktualisiert werden, und es scheint, dass anschließend eine manuelle Bereinigung des Arbeitsbereichs erforderlich ist, damit Hudson "erkennt", dass es jetzt mehr Projekte als früher gibt. Dies hat jetzt für ein paar Monate gut für uns funktioniert, aber es war ziemlich mühsam, alles in der Ameisen-Datei arbeiten zu lassen.
Edit: Die "Team Projekte verwenden" mit ant4eclipse und einem Ctrl-A, Strg-C im Projekt Panel mit einem Ctrl-V in den CVS Projekten in Hudson hat sich als gut genug herausgestellt, um damit zu leben reife Projekte wird dies sehr selten geändert). Ich erwarte die Veröffentlichung von ant4eclipse 1.0 - Ссылка , derzeit in Meilenstein 2 - um zu sehen, wie viel Eigenbau-Funktionalität durch ant4eclipse-Dinge ersetzt werden kann.
Bearbeiten: ant4eclipse ist ab 20100609 in M4, so dass der Zeitplan bei Ссылка etwas nachlässt.
>Edit: Meine Schlussfolgerung nach längerer Verwendung unseres ant4eclipse-Ansatzes ist, dass das Build-Skript sehr knorrig wird und schwer zu pflegen ist. Auch die Team ProjectSet-Funktion (mit der ant4eclipse die Projekte lokalisieren kann) funktioniert gut für CVS-basierte Repositories, aber nicht nachdem wir zu git migriert sind (was eine große Sache für sich ist). Neue Projekte werden höchstwahrscheinlich auf Maven basieren, da dies in Jenkins gute Unterstützung findet.
Schreiben Sie ein Hudson-Plugin, das versteht das Ableiten von projectSet.psf eine Konfiguration und erstellen Sie es.
Das scheint mir die beste Antwort zu sein.
Ich arbeite eher mit CruiseControl als mit Hudson, aber nach meiner Erfahrung kann es sich schnell auszahlen, wenn Sie ein Plugin erstellen, das Ihr Problem löst. Und es ist im Allgemeinen ziemlich einfach, ein Plugin zu schreiben, das für Ihre Lösung maßgeschneidert ist, im Gegensatz zu einem, das für alle in einer ähnlichen Situation funktionieren muss.
Ich bin mir nicht ganz sicher, ob ich das Problem verstehe, aber es hört sich so an, als ob das Hauptproblem darin besteht, dass Sie viele Projekte haben, von denen einige von anderen abhängig sind. Einige der Projekte, die näher am "Blatt" des Abhängigkeitsbaums sind, müssen in der Lage sein, "stabile" (oder zuvor "freigegebene") Versionen der mehr "Kern" -Projekte zu verwenden.
Ich löse genau dieses Problem mit Hudson , ant und Efeu . Ich folge einem Muster, das Clark in Pragmatischer Projektautomatisierung demonstriert hat (er zeigt nicht die Abhängigkeitsprobleme und Lösungen, und Er verwendet CruiseControl anstelle von Hudson.)
Ich habe eine handgeschriebene Ameisen-Build-Datei (wir nennen sie "cc-build.xml", wegen unserer CruiseControl-Wurzeln.) Diese Datei ist dafür zuständig, den Arbeitsraum für das Projekt vom CM-Repository zu aktualisieren und zu kennzeichnen Inhalt für zukünftige Referenz. Es übergibt dann die Kontrolle an eine andere handgeschriebene Ameisen-Build-Datei (build.xml), die von den Entwicklern jedes Projekts bereitgestellt wird. Dieses Projekt ist für die herkömmlichen Build-Schritte (Kompilieren, Packen usw.) verantwortlich. Es ist erforderlich, die installierbaren Artefakte, Komponententestberichte usw. in das Hudson-Artefakte-Verzeichnis auszuspucken. Es ist meine Erfahrung, dass automatisch generierte Build-Dateien (von Eclipse oder anderen ähnlichen IDEs) niemals annähernd so robust sind, dass sie in einem CI-Szenario verwendet werden können.
Außerdem verwendet es ivy, um seine eigenen Abhängigkeiten aufzulösen. Ivy unterstützt genau spezifizierte Abhängigkeitsversionen (zB "benutze Version 1.1") und unterstützt "unscharfe Versionen" (zB "benutze Version 1.1+" oder "nutze die neueste Version im Integrationsstatus"). Unsere Projekte beginnen typischerweise mit der Angabe sehr "Fuzzy" -Version für interne Projekte, die sich in der laufenden Entwicklung befinden, und wenn sie einem Release-Punkt nahe kommen, "frieren" sie die Abhängigkeitsversion ein, so dass sich die Dinge nicht mehr unter ihnen bewegen.
Die Non-Leaf-Projekte (Projekte, die von anderen Projekten abhängig sind) verwenden ebenfalls efeu, um ihre Artefakte in unserem internen Efeu-Repository zu veröffentlichen. In diesem Repository werden alle früheren Builds der Abhängigen beibehalten, sodass jedes Projekt immer von einer anderen vorherigen Version abhängig sein kann.
Schließlich ist jedes Projekt in Hudson so konfiguriert, dass es einen Build-Trigger hat, der eine Neuerstellung verursacht, wenn eines seiner abhängigen Projekte erfolgreich erstellt wird. Dadurch werden sie mit der (möglicherweise) neuen Efeu-abhängigen Version wieder aufgebaut.
Es ist erwähnenswert, dass, sobald Sie dies eingerichtet haben, das konsistente automatisierte "etikettieren" oder "taggen" der Eingaben eines automatisierten Builds für Sie von entscheidender Bedeutung sein wird - ansonsten wird die Behebung von Post-Build-Problemen dazu führen ein Hornissennest entwirren, um die ursprüngliche Quelle zu finden.
Um all diese Einstellungen für unsere Umgebung zu erhalten, waren einige Anstrengungen nötig (vor allem beim Einrichten des Efeu-Repositorys und der Ameisen-Build-Dateien), aber es hat sich beim manuellen Verwalten der Abhängigkeiten um ein Vielfaches bezahlt gemacht und abgenommen Fehlerbehebung Aufwand.
Ich habe sowohl Cruise Control (CC) als auch Hudson für unsere CI-Lösung ausprobiert. Wir (als Unternehmen) entschieden uns für Hudson. Aber für Ihre Frage "Unterstützt CC Eclipse Projekt Build" ist die Antwort nicht so weit wie ich weiß. CC unterstützt viele andere Build-Tools und Source-Control-Systeme, aber es ist ein wenig schwieriger zu konfigurieren und zu verwenden. Wie für Hudson ist es einfacher zu konfigurieren und zu verwenden. Wir haben unsere benutzerdefinierten Plugins für CC und Hudson für die Teile unseres Build-Zyklus entwickelt, die sie nicht so bereitstellen wie sie sind. Wie für die Entwicklung von Plugins, wenn Sie Maven kennen / verwenden, ist Hudson auch einfacher. Aber wenn Sie mit Maven nicht vertraut sind, müssen Sie zunächst die grundlegende Verwendung von Maven lernen, um ein Hudson-Plugin erfolgreich zu entwickeln. Aber sobald Sie die grundlegende Verwendung von Maven verstehen, ist Plugin-Entwicklung, Test und sogar Debugging einfacher in Hudson.
Für Ihr spezifisches Problem kann ich mir eine Lösung vorstellen, die auch Eclipse-Plugins nutzt. Sie können ein eigenes Eclipse-Plugin entwickeln, das zum Beispiel die psf-Dateien aus einem (konfigurierbaren) Ordner bezieht und Eclipse-Interna verwendet, um diese psf-Dateien zu verarbeiten. Ich meine, Sie können vorhandene Eclipse-Quellcodes verwenden, die eine PSF-Datei verwenden, ihre Projektdefinitionen auschecken und diese Projekte kompilieren. Dieses Eclipse-Plugin von dir kann eine Präferenzseite haben (auf die du über Eclipse zugreifen kannst - & gt; Window - & gt; Einstellungen) und konfigurieren, welchen Ordner es verwenden soll, um nach psf-Dateien zu suchen. Ihr Eclipse-Plugin sollte auch eine Möglichkeit bieten, die psf-Verarbeitung ohne Benutzerinteraktion zu starten. Dazu können Sie Ihren Prozess mit ipc auslösen. Ich meine, Ihr Eclipse-Plugin kann auf einen Port warten, und Sie können eine andere Java-Anwendung schreiben, die sich über diesen Port mit Ihrem Plugin verbindet und dessen Prozess auslöst. Wie beim CI-Teil können Sie entweder CC oder Hudson verwenden und ihre externe Unterstützung für die Prozessausführung verwenden. Wenn Sie Windows verwenden, können Sie eine Fledermausdatei (für Linux sh-Datei) schreiben, die Eclipse startet, auf der Ihr Plugin installiert ist. Dann startet es Ihre Java-Anwendung, die mit Ihrem Eclipse-Plugin kommunizieren wird, um Ihren Prozess auszulösen. Von Ihrem CI-Tool müssen Sie Ihre bat / sh-Datei ausführen, um Ihren Prozess auszulösen.
Tags und Links eclipse java continuous-integration hudson cvs