Frage

Ich habe eine ziemlich große Anwendung (mehrere MLOCs) zur Hand, die ich gerne in besser wartbare separate Teile aufteilen möchte.Derzeit besteht das Produkt aus etwa 40 Eclipse-Projekten, von denen viele gegenseitige Abhängigkeiten aufweisen.Dies allein macht ein kontinuierliches Build-System undurchführbar, da es bei jedem Check-in sehr viel neu erstellen müsste.

Gibt es eine „Best Practice“-Methode dafür?

  • Identifizieren Sie Teile, die sofort getrennt werden können
  • Zusammenhänge visuell dokumentieren
  • Entwirren Sie den vorhandenen Code
  • Behandeln Sie „Patches“, die wir auf Bibliotheken anwenden müssen (derzeit werden sie dadurch gehandhabt, dass sie vor der eigentlichen Bibliothek in den Klassenpfad eingefügt werden).

Wenn es (kostenlose/offene) Tools gibt, die dies unterstützen, würde ich mich über Hinweise freuen.

Auch wenn ich keine Erfahrung mit Maven habe, scheint es, als würde es ein sehr modulares Design erzwingen.Ich frage mich jetzt, ob dies etwas ist, das iterativ nachgerüstet werden kann, oder ob ein Projekt, das es verwenden sollte, von Anfang an auf Modularität ausgelegt werden müsste.

Bearbeiten 10.07.2009

Wir sind dabei, einige Kernmodule aufzuteilen Apache-Ameise/Efeu.Wirklich hilfreiches und gut gestaltetes Tool, das Ihnen nicht so viel auferlegt wie Maven.

Ich habe in meinem Blog einige allgemeinere Details und eine persönliche Meinung darüber niedergeschrieben, warum wir das tun – zu lang, um sie hier zu veröffentlichen, und vielleicht nicht für jeden interessant, also folgen Sie ihnen nach eigenem Ermessen: www.danielschneller.com

War es hilfreich?

Lösung

Mit OSGi könnte eine gute Passform für Sie. Es würde erlauben Module aus der Anwendung zu erstellen. Sie können auch Abhängigkeiten in einer besseren Art und Weise organisieren. Wenn Sie Ihre Schnittstellen zwischen den verschiedenen Modulen richtig definieren, dann können Sie die kontinuierliche Integration verwenden, wie Sie nur das Modul neu zu erstellen, die Sie beim Check-in berührt.

Die Mechanismen, durch OSGi bereitgestellt wird Ihnen helfen, den vorhandenen Code zu entwirren. Aufgrund der Art und Weise des Classloading funktioniert, auch hilft es Ihnen, die Patches in einem einfacheren Weg zu behandeln.

einige Konzepte von OSGi, die ein gutes Spiel für Sie zu sein scheinen, wie aus wikipedia gezeigt:

Der Rahmen konzeptionell in die folgenden Bereiche unterteilt:

  • Bundles - Bundles sind normale jar Komponenten mit zusätzlichem Manifest Header
  • .
  • Dienste -. Die Dienstschicht Bündel in einer dynamischen Art und Weise verbindet, indem ein Publish-Find-Bind-Modell für Plain Old Java Objects (POJOs) anbieten
  • Services Registry. - Die API für Managementdienste (ServiceRegistration, Servicetracker und Servicereference)
  • Life-Cycle -. Die API für Life Cycle Management (installieren, starten, stoppen, aktualisieren und deinstallieren Bundles)
  • Module -. Die Schicht, die Verkapselung und Deklaration von Abhängigkeiten definiert (wie ein Bündel und Export Code importieren)
  • Sicherheit -. Die Schicht, die die Sicherheitsaspekte durch die Begrenzung Bündel Funktionalität Griffe auf vordefinierte Funktionen

Andere Tipps

Erstens: viel Glück und guten Kaffee. Sie werden beide benötigen.

Ich hatte mal ein ähnliches Problem. Legacy-Code mit schrecklichen zirkulären Abhängigkeiten, auch zwischen den Klassen aus verschiedenen Paketen wie org.example.pkg1.A hängt von org.example.pk2.B und vice versa.

Ich begann mit maven2 und frischen Eclipse-Projekten. Zuerst habe ich versucht, die am häufigsten verwendeten Funktionen (Logging Schicht, gemeinsame Schnittstellen, gemeinsame Dienste) und erstellt Maven Projekte zu identifizieren. Jedes Mal, wenn ich war glücklich mit einem Teil, setzte ich die Bibliothek an die zentralen Nexus-Repository, so dass es auch für andere Projekte fast sofort zur Verfügung stand.

So arbeitete ich langsam durch die Schichten nach oben. maven2 behandelt die Abhängigkeiten und die m2eclipse Plugin eine hilfreiche Abhängigkeit Ansicht zur Verfügung gestellt. BTW - es ist in der Regel nicht allzu schwierig, ein Eclipse-Projekt in ein Maven-Projekt zu konvertieren. m2eclipse kann es für Sie tun, und Sie haben nur ein paar neue Ordner erstellen (wie src / main / java) und den Build-Pfad für Quellordner anpassen. Dauert nur eine Minute oder zwei. Aber mehr Schwierigkeiten erwarten, wenn Ihr Projekt eine Eclipse-Plugin oder RCP-Anwendung ist und Sie wollen maven nicht nur Artefakte zu verwalten, sondern auch die Anwendung zu erstellen und bereitzustellen.

Um Meinung, Eclipse, Maven und Nexus (oder ein anderer Maven-Repository-Manager) ist eine gute Basis zu beginnen. Du hast Glück, wenn Sie eine gute Dokumentation der Systemarchitektur haben und diese Architektur wirklich umgesetzt wird;)

Ich hatte eine ähnliche Erfahrung in einer kleinen Code-Basis (40 kloc). Es gibt keine Regeln ° ":

  • zusammengestellt mit und ohne "Modul", um es zu sehen ist Nutzung
  • Ich begann von „Blatt Module“, Module ohne andere Abhängigkeiten
  • I zyklische Abhängigkeiten behandelt (dies ist eine sehr fehleranfällige Aufgabe)
  • mit Maven gibt es sehr viel mit der Dokumentation (Berichte), die bereitgestellt werden können, in Ihrem CI-Prozess
  • mit Maven können Sie immer sehen, was verwendet, was sowohl in der Website sowohl in NetBeans (mit einem
    sehr schön gerichteten Graphen)
  • mit Maven können Sie Bibliothekscode in Ihrer Code-Basis importieren, gelten Source-Patches und kompilieren mit Ihren Produkten (manchmal manchmal sehr einfach ist, ist es sehr schwer)

Überprüfen Sie auch Dependency Analyzer:
(Quelle: javalobby.org )

Netbeans:


(Quelle: zimmer428.net )

Maven ist schmerzhaft für ein bestehendes System zu migrieren. Allerdings kann es mit mehr als 100-Modul-Projekten ohne große Schwierigkeiten bewältigen.

Als Erstes müssen Sie entscheiden, in welche Infrastruktur Sie umziehen möchten.Soll es sich um viele unabhängig verwaltete Module handeln (was sich auf einzelne Eclipse-Projekte übertragen lässt) oder betrachten Sie es als einen einzelnen Codeblock, der als Ganzes versioniert und bereitgestellt wird?Ersteres eignet sich gut für die Migration zu einer Maven-ähnlichen Build-Umgebung – letzteres, um den gesamten Quellcode auf einmal zu haben.

In jedem Fall benötigen Sie ein kontinuierliches Integrationssystem.Ihre erste Aufgabe besteht darin, die Codebasis automatisch erstellen zu lassen, damit Ihr CI-System Ihr Quell-Repository überwachen und es neu erstellen kann, wenn Sie Änderungen vornehmen.Ich habe mich hier für einen Nicht-Maven-Ansatz entschieden, und wir konzentrieren uns auf eine einfache Eclipse-Umgebung, also habe ich eine Build-Umgebung mit ant4eclipse- und Team ProjectSet-Dateien (die wir sowieso verwenden) erstellt.

Der nächste Schritt besteht darin, die zirkulären Abhängigkeiten zu beseitigen. Dadurch wird Ihr Build einfacher, Eclipse-Warnungen werden beseitigt und Sie können schließlich zur Phase „Auschecken, einmal kompilieren, ausführen“ gelangen.Dies kann eine Weile dauern :-( Wenn Sie Methoden und Klassen migrieren, VERSCHIEBEN Sie sie nicht, sondern extrahieren oder delegieren Sie sie und lassen Sie ihren alten Namen herumliegen und markieren Sie sie als veraltet.Dadurch wird Ihr Entangeling vom Refactoring getrennt, und Code „außerhalb“ Ihres Projekts kann weiterhin mit dem Code innerhalb Ihres Projekts funktionieren.

Sie profitieren von einem Quell-Repository, das das Verschieben von Dateien und das Aufbewahren des Verlaufs ermöglicht.CVS ist in dieser Hinsicht sehr schwach.

würde ich Maven nicht für eine Legacy-Source-Code-Basis empfehlen. Es könnten Sie viele Kopfschmerzen nur versuchen, alles zu passen, mit ihm zu arbeiten.

Ich nehme an, was Sie brauchen, ist ein architektonisches Layout Ihres Projekts zu tun. Ein Werkzeug könnte helfen, aber der wichtigste Teil ist eine logische Ansicht der Module zu organisieren.

Es ist nicht kostenlos, aber Structure101 werden Sie so gut geben, wie Sie in Bezug auf die Werkzeug bekommen Unterstützung für alle Ihre Aufzählungspunkte schlagen. Aber für die Platte, die ich bin voreingenommen, so dass Sie vielleicht zu SonarJ und Lattix zu überprüfen. ; -)

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top