Wie kann ich einen Eclipse .classpath Eintrag für bestimmte O/S-Plattform angeben?

Question

Ich arbeite an einem SWT-Projekt als Teil eines Teams. Wir brechen ständig jede andere Build-Umgebung, weil Eclipses .classpath-Datei in die Versionskontrolle eingecheckt wird und wir verschiedene SWT-Bibliotheken für unsere Maschinen enthalten.

Je nachdem, wer die letzte Änderung vorgenommen hat, kann der .classpath-Eintrag lauten:

<classpathentry kind="lib" path="lib/swt/swt-win32.jar"/>

o

<classpathentry kind="lib" path="lib/swt/swt-carbon.jar"/>

o

<classpathentry kind="lib" path="lib/swt/swt-gtk.jar"/>

Es scheint, dass sich die Bibliotheken gegenseitig ausschließen, d.h. man kann sie nicht alle auf einmal einbinden und SWT das erledigen lassen. Also müssen wir sie für jede Plattform irgendwie filtern...

Hat jemand eine Idee, wie man das machen könnte? Meine ursprüngliche Idee war, dies in seine eigene ".classpath-swt" Datei (ignoriert von der VCS) zu teilen, automatisch generieren es mit Ant und fügen Sie es in der Haupt-.classpath, aber es scheint, Eclipse unterstützt nicht die Aufteilung der .classpath-Datei.

Unsere derzeitige Lösung besteht darin, den Klassenpfad nur dann zu übermitteln, wenn wir die Abhängigkeiten tatsächlich geändert haben. Dies bedeutet jedoch, dass eine Reihe von Personen ihre Entwicklungsumgebungen jedes Mal anpassen müssen, wenn der Klassenpfad geändert wird.

Jeder Vorschlag wird sehr geschätzt, solange es nicht "don't use Eclipse", da dies nicht eine Option für dieses Projekt ist :)

Answer 1

In Eclipse können Sie Klassenpfadvariablen definieren, so dass Sie den Klassenpfad beibehalten können, aber jeder Entwickler würde sein Eclipse je nach Plattform konfigurieren. Sie könnten dann zumindest die .classpath-Datei versionieren. Sie müssen die Verzeichnisstruktur, in der Sie Ihre SWT-Jars speichern, so ändern, dass sich der Jar-Name nicht pro Plattform ändert. Dieses Menü ist zu finden unter: " Fenster->Einstellungen->Java->Build-Pfad "

SWTJARDIRECTORY/
    WIN32/
        SWT.JAR
    CARBON/
        SWT.JAR
    GTK/
        SWT.JAR

Ex.

    SWT_PLATFORM="SWTJARDIRECTORY/GTK", set by developer in Eclipse

.klassenpfad

    SWT_PLATFORM/SWT.JAR

Answer 2

Sie sollten diese Bibliotheken in einem separaten, leicht identifizierbaren Projekt haben, anstatt sie in jedem einzelnen Projekt zu platzieren.

Erstellen Sie z.B. ein Projekt mit dem Namen "00-swt-provider" (damit es ganz oben steht) und lassen Sie es auf eines von "00-swt-provider-carbon", "00-swt-provider-win32" oder "00-swt-provider-gtk" verweisen.

Beide exportieren die entsprechenden nativen Bibliotheken für die jeweilige Plattform, und der einzige Link befindet sich in 00-swt-provider. Das eigentliche Projekt verweist nur auf dieses Metaprojekt.

Wir verwenden intern eine Variante dieser Methode, die bei uns gut funktioniert.

Answer 3

Wie wäre es, wenn Sie einfach Ihre eigenen Instanzen konfigurieren und diese eine Komponente Ihrer Umgebung nicht in der Versionskontrolle aufbewahren?

Alternativ könnten Sie eine Klassenpfaddatei für jede Umgebung speichern, vielleicht in einem anderen Verzeichnis, und in einer Ant-Datei, z. B. der build-setup-env.xml-Datei, könnten Sie einfach ein Ziel für jede Umgebung haben, das das richtige Ziel kopiert. Um eine Kopie davon in der Versionskontrolle zu behalten, müssten Sie sicher sein, dass Sie sie zurückkopieren, wenn sie aktualisiert wird.

Answer 4

SWT tut dies durch no Versionierung der .classpath-Datei, sondern durch Versionen mehrerer separater .classpath_*-Dateien mit angehängtem Betriebssystem und Fenstersystem, z.B. .classpath_win32_win32. Wenn Sie also die Quellen aus dem Repository auschecken, wird von Ihnen erwartet, dass Sie die entsprechende Klassenpfaddatei nach .classpath kopieren und Ihr Projekt neu kompilieren.