So drücken Sie Inter -Projektabhängigkeiten in Eclipse PDE aus

Question

Ich suche nach den besten Praxis, Inter-Projekt-Abhängigkeiten zwischen gemischten Projekttypen zu verarbeiten, bei denen einige Projekte Eclipse Plug-in/OSGI-Bundle-Projekte (eine RCP-Anwendung) sind, und andere sind einfach alte Java-Projekte (Web Services Module). Nur wenige der Eclipse-Plug-Ins haben Abhängigkeiten von Java-Projekten.

Mein Problem ist, dass es zumindest soweit ich ausgesehen habe, dass es keine Möglichkeit gibt, eine solche Abhängigkeit in der Eclipse -PDE -Umgebung sauber auszudrücken. Ich kann Plug-in-Projekte haben, die von anderen Plug-in-Projekten abhängen (über Import-Package oder Require-Bundle offensichtliche Header), aber nicht der einfachen Java -Projekte.

Ich scheinen in der Lage zu sein, eine Projektabhängigkeit von einem Jar -Projekt in einem Arbeitsbereich zu deklarieren, aber diese JAR -Dateien werden weder durch Export- noch Startkonfiguration abgeholt (obwohl die Bearbeitung von Java -Code die Bibliotheken in Ordnung sieht).

Die "Java -Projekte" werden für den Bau von Diensten verwendet, die in einem J2EE -Container (momentan) in einem J2EE -Container eingesetzt werden und in einigen Fällen in mehreren Fällen produziert werden - eine für die Bereitstellung für das JBoss -Ohr und eine andere zur Verwendung durch Client -Code (ein RCP -Anwendung).

Die Art und Weise, wie wir dieses Problem vorerst "gelöst" haben, ist, dass wir 2 weitere Konfigurationen für externe Tools -Launcher haben - eines für das Erstellen aller JARs und eines für das Kopieren dieser JARs in die Plug -in -Projekte. Dies funktioniert (irgendwie), aber das "ganze Build" und "Kopieren von Jars" -Zielen entstehen einen ziemlich großen Bauschritt, wobei die gesamte inkrementelle Build -Funktion umgangen wird und die JARs kopieren, anstatt nur die Projekte zu verweisen, die ich die Abhängigkeitsinformationen entkoppele und eine massive Aktualisierung des Arbeitsbereichs zu fordern, die die Entwicklungszeit wie Süßigkeiten auffrischt.

Was ich gerne hätte, ist ein viel "natürlicheres" Arbeitsbereichsaufbau, das Abhängigkeiten zwischen Projekten verwalten und inkrementelle Neuaufbaustoffe nur so wie benötigt, in der Lage sein, Client-Code von Dienstbibliotheken in einem RCP-Anwendungs-Plug-Ins zu verwenden und in der Lage zu sein So starten Sie die RCP -Anwendung mit allen erforderlichen Klassen, in denen sie benötigt werden.

Kann ich meinen Kuchen haben und ihn auch essen;)

HINWEIS

Um klar zu sein, geht es derzeit nicht so sehr um Abhängigkeitsmanagement und Modulverwaltung wie um die Eclipse -PDE -Konfiguration.

Ich bin mir von Produkten wie [Maven], [Ivy] und [Buckminster] sehr bewusst und sie lösen ein ganz anderes Problem Produkt)

Answer 1

Ich habe es nie getan, also ist dies ein theoretischer Ansatz. Aber ich würde ein Abhängigkeitsmanagementsystem wie Ivy oder Maven2 ausprobieren.

Da Maven2 viel mehr tut, dann würde ich in diesem Fall Ivy empfehlen.

Answer 2

Eclipse -Projekte hängen aufgrund des Kontrollkästchens in den Eigenschaften des Projekts (abhängige Projekte?) Voneinander ab. Wie entscheidet die Eclipse, welche sie erstellen sollen. Sie können dies selbst einstellen, aber es wird normalerweise festgelegt, wenn Sie Ihren Java -Build -Pfad ändern. Es speichert die Daten in der .Project -Datei IIRC. Sobald Sie die GUI durchgemacht haben und gesehen haben, was sich ändert, können Sie flexibler sein, wie Sie die anderen anwenden.

Es hört sich jedoch so an, als wollten Sie Gläser und Bündel mischen und kombinieren. Die einfache Möglichkeit, dies zu tun, besteht darin, alle Projekte als Java -Projekte zu behandeln. Im PDE -Projekt können Sie tatsächlich den Java -Build -Pfad anpassen und optimieren. Es wird sich beschweren und sagen, dass es nicht der richtige Weg ist, es zu tun, aber es wird Ihnen ermöglichen, ein PDE -Projekt von einem Java -Projekt abhängt, ohne all das flauschige Jaring zu haben. Trotzdem würde es mich nicht überraschen, wenn es mit diesem Ansatz Probleme mit der Laufzeit gäbe - die PDE -Laufzeit wird es wahrscheinlich nicht so sehen.

Der andere Ansatz besteht darin, Ihre Gläser selbst PDE/OSGI -Bündel zu machen. Schließlich ist ein OSGI -Bündel nichts weiter als ein Glas mit etwas zusätzlicher Treue im Manifest, und Sie können Ihre Projekte mit dem automatischen Abhängigkeitsmanagement trivial entwickeln und zusammenstellen. Das ist wahrscheinlich das einfachste, das man am einfachsten entscheiden kann, auch wenn Sie das Manifest nicht wirklich brauchen, um in Ihren Bundles präsent zu sein. Dies bedeutet jedoch, dass Ihre PDE -App mit einem modulareren Ansatz versendet werden kann, anstatt die Bibliotheken nach Bedarf in jedes Plugin einzubetten.

PDE kann also OSGI -Bündel erzeugen, und das ist nur ein anderer Name für Jar + Manifest -Sachen. Sie können ein Glas in anderen Umgebungen genau auf die gleiche Weise verwenden (z. B. für Ihr Ohr oder andere Kunden verwendet) und die OSGI -Ebene in Ihrer App nutzen. Es gibt wirklich keinen Grund, dies angesichts der Art des Hybridbündels, über das Sie sprechen, nicht zu tun.

Answer 3

Unsere Lösung verwendet einen Ant -Builder, um die "Klassen" -Verzeichnungen der Plain Java -Projekte direkt in das oberste Verzeichnis des Plugin -Projekts zu kopieren. Wir überspringen den Schritt des Glasgebäudes, um Zeit zu sparen, und es funktioniert ziemlich gut. Wenn das Plugin -Projekt von externen Gläser abhängt, die bereits gebaut wurden, kopieren wir auch diese.

Hier ist genau, wie Sie es in Eclipse 3.5 einrichten können (Entschuldigung für die seltsame Formatierung, aber nur so kann ich feststellen, dass ich die Eindrücke erhalten habe):

Create empty "classes" dir in plugin project
Select plugin project, hit F5 to refresh resources
Create new Ant build file in plugin project to copy dependencies (ours is shown below)

Right-click plugin project, select Properties
  Select Builders
  Click "New..." (brings up Edit Configuration dialog)
    Select Ant Builder and click "OK"
    Name your builder (ours is called "PluginProject externals")
    Browse workspace for Buildfile (ours is ${workspace_loc:/PluginProject/copyDependencies.xml})
    click Refresh tab
      check "Refresh resources upon completion", click "Specific resources"
      click "Specify Resources...", check box for the classes dir, click "Finish"
  Click "OK" (closes Edit Configuration dialog)
  Click "Up" to move "PluginProject externals" to top of builder list
Click "OK" (closes Properties dialog)

Open your plugin project's MANIFEST.MF
Click "Runtime" tab
Click "Add..." under "Classpath", select your the "classes" dir and JARs and click "OK"

Die manuelle Erstellung des leeren "Klassen" -Verstellungsverzeichnisses im Plugin -Projekt ist so, dass Sie Ihrem neuen Bauunternehmer diese Ressource aktualisieren können (was noch nicht vorhanden ist, bevor der neue Bauherr ausgeführt wird). Hier ist, was in unserer Datei copyDependencies.xml steckt:

<project name="Copy dependencies" default="copyDependencies" basedir=".">
  <!--
    This copying is needed because it appears that Eclipse plugins can't
    depend directly on external Eclipse projects.
  -->
  <description>
    Copies external dependency class andd JAR files into this plugin's directory.
  </description>

  <target name="copyDependencies">
    <copy file="../External/JDOM/jdom-1.0/build/jdom.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xalan.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xercesImpl.jar" todir="." preservelastmodified="true"/>
    <copy file="../External/Xalan/xalan-j_2_6_0/bin/xml-apis.jar" todir="." preservelastmodified="true"/>
    <copy todir="./classes/com/arm" preservelastmodified="true">
      <fileset dir="../Utilities/src/com/arm" excludes="**/*.java"/>
    </copy>
  </target>
  <target name="clean" description="Deletes local copies of external classes and JARs.">
    <delete file="jdom.jar" quiet="true"/>
    <delete file="xalan.jar" quiet="true"/>
    <delete file="xercesImpl.jar" quiet="true"/>
    <delete file="xml-apis.jar" quiet="true"/>
    <delete dir="./classes/com/arm/utilities" quiet="true"/>
  </target>
</project>

Der einzige Nachteil dieser Methode scheint zu sein, dass Eclipse nicht zu 100% perfekt ist, wenn es darum geht, den externen Bauunternehmer aufzurufen, wenn er aufgerufen werden muss. Gelegentlich müssen Sie in der Eclipse ein "Projekt> sauber ..." durchführen, um es mitzumachen .

Answer 4

Du hast mein Mitgefühl. Auch ich habe mit diesem Problem und der Wand der Scheibenz der Eclipse-Entwickler in einer so einfachen, offensichtlichen Frage gekämpft: Wie kann man eine Abhängigkeit von einem Plugin zu einem normalen Java-Projekt deklarieren (so dass es zur Laufzeit funktioniert)?

Ich glaube nicht, dass sie es unterstützen. Die einzige Möglichkeit, das Problem umzugehen, besteht darin, Ordner in meinen Plugin -Projekten zu erstellen, die tatsächlich Links zu den Bin/ Ordnern der Java -Projekte sind und diese Ordner dann in das Plugin einbeziehen. Das funktioniert zumindest, aber es ist brüchig aufgrund der erforderlichen absoluten Dateisystempfade.

Answer 5

Vielleicht können Sie "Projekteigenschaften" -> "Bereitstellungsversammlung" auf Eclipse verwenden und Ihrem Hauptprojekt andere Projekte hinzufügen. Die anderen Projekte sehen wie "Gläser", die automatisch Ihrer Bereitstellungsdatei (Krieg, Ohr oder was auch immer) hinzugefügt werden. Vielleicht kann das funktionieren. Zumindest funktioniert es für mich. Viel Glück !!

Ariesandes.

Answer 6

In Build -Pfadeigenschaften gibt es eine Option "Link -Quelle", mit der Sie zusätzliche Quellordner für ein Projekt definieren können. Sie können den Ordner "SRC" eines anderen Arbeitsbereichsprojekts auswählen und in "SRC2" oder was auch immer Sie wollen. Auf diese Weise werden die Klassen zusammengestellt und im Plug-in-Projektausgangsordner bereitgestellt und können zur Laufzeit geladen werden.

Answer 7

Mit einer komplexen Reihe von Build -Abhängigkeiten habe ich festgestellt, dass Maven2 und Hudson (damit CI) eine ziemlich schöne Kombination ist. Es dauerte eine Weile, um die Infrastruktur einzurichten und den Kopf zu machen, aber danach hat es einfach funktioniert.

Natürlich sind Sie dann von der Unterstützung von Maven2 (oder Hudson) für Ihren Baumechanismus abhängig. Ich bin mir nicht sicher, wie gut Eclipse Headless Builds unterstützt werden. Wenn Sie jedoch nur mit Eclipse kopflos verwenden, besteht darin, dass die Abhängigkeiten an einem einzigen Ort ausgedrückt werden, tun Sie sich selbst einen Gefallen und wechseln.

Answer 8

Ich habe genau die gleichen Probleme. Wir haben eine Reihe mehrerer normaler Java -Projekte, die von Maven erstellt werden können und sollten (derzeit) alle denselben Klassenpfad teilen, um ordnungsgemäß zu funktionieren. Diese Projekte können verwendet werden, um einen Server in einer Nicht-OSGI-Umgebung zu starten. Dann haben wir auch einen Eclipse RCP -Client, der diese Projekte als ein Bundle verwendet. Ich bin perfekt in der Lage, dieses One-Big-Bangle mit Maven mit dem Apache Felix Maven-Bundle-Plugin zu bauen, und alles funktioniert einwandfrei. Aber wenn ich eine Klasse im normalen Projekt ändere, muss ich das gesamte Bundle wieder aufbauen. Inkrementelle Build und Ressourcenverbindung funktionieren nicht.

Ich habe die "Lösung" mit der Verknüpfung von Binärdaten/Quellverzeichnissen aus diesen Projekten in den offensichtlichen Klassenpfad der One-Big-Bunde ausprobiert, und es scheint zu funktionieren, aber es wäre ein echter Alptraum für Wartung, weil ich sogar einige einzelne Dateien verknüpfen muss.

Ironischerweise denke ich aufgrund der Verwendung von OSGI im Kunden daran, unsere schöne und modulare Struktur mit Maven -Modulen in Unterpackungen von nur einem Plugin -Projekt zu kollabieren. Dies ist eine bessere Alternative als eine extrem langsame Entwicklung.

Die andere und bessere Alternative (laut OSGI -Jungs), die ich zuerst untersuchen werde, ist, alle meine Maven -Module in OSGI -Bündel zu machen. Dies kann jedoch eine echte Pita sein, da ich vom Scannen und Kombinieren mehrerer Konfigurationsdateien aus mehreren Bündeln (mit manchmal mit demselben Namen) zu einer Konfiguration abhängig bin.

(Insbesondere verwenden wir das Spring Framework und fusionieren multiple persistenz.xml -Dateien in einen Persistenzkontext. Wir verschmelzen auch mehrere Spring -XML -Kontextdateien aus verschiedenen Modulen (alle einen anderen Aspekt bereitstellen), der zusammen einen Federkontext bilden sollte, der von Frühling verwendet werden soll, zusammen -DM.)