Aktuelles Eclipse selber paketieren

Seit meine Erinnerung zurückreicht wurde Eclipse von den Debian- und Ubuntu-Maintainern immer recht stiefmütterlich behandelt. Die sowohl in Ubuntu Natty als auch in Debian Sid verfügbare Version ist 3.5, obwohl seit Juni 2010 3.6 verfügbar ist. Externe Paketquellen habe ich bisher nicht gefunden (außer die hier, Eclipse stürzt hier nach dem Start ab und sie ist auch nicht für Natty gedacht), offensichtlich scheinen wenig Leute Interesse daran zu haben, Eclipse zu paketieren.

Ein Grund für die zögerliche Paketierung könnte sein, dass Eclipse ja bereits eine interne Paketverwaltung mitbringt, über die Plugins mittels Paketquellen installiert werden können. Sogar auf dem App-Store-Zug sind die Entwickler aufgesprungen. Hier stellt sich die Frage, ob man Plugins auch mitpaketieren sollte, was von Debian und Ubuntu jedenfalls für beliebte Plugins gemacht wird. Da es nicht oder nur mit großem Aufwand möglich ist, APT und die Eclipse-Paketverwaltung zur Zusammenarbeit zu bewegen, existieren sie nebeneinander und das find ich unschön. Ich benutze nicht gerne zwei Werkzeuge parallel für den selben Zweck, ich möchte nicht einen Teil meiner Plugins über APT verwalten und den anderen Teil über Eclipse selbst.

Deswegen bin ich dazu übergegangen, mir nur ein “nacktes” Eclipse über APT zu installieren und die Plugins über Eclipse selber. In den Paketquellen gibt es ja das Paket eclipse-platform, welches ein solches nacktes Eclipse enthält, aber wie oben erwähnt veraltet ist. Das lässt sich aber dadurch kompensieren, indem man sich Eclipse selbst über die Projektseite herunterlädt und in ein eigenes Paket verbaut.

Auf der Download-Seite werden aber nur vorkonfigurierte Bundles angeboten, die bereits irgendwelche Plugins enthalten. Etwas versteckt lässt sich aber eine pluginlose Version besorgen, indem man auf diese Seite geht und bis zu “Platform Runtime Binary” scrollt. Hier muss die für die Rechnerarchitektur passende Version heruntergeladen werden.

In diesem Beispiel nutze ich amd64/x86_64. Wer eine andere Architektur hat, 
muss die Befehle oder Datei-Inhalte ggf. anpassen, also nicht einfach den Guttenberg machen.

Bevor losgelegt werden kann, müssen aber noch einige Tools installiert…

$ sudo apt-get install fakeroot dpkg-dev debhelper unp

…und ein Arbeitsverzeichnis angelegt werden:

$ mkdir eclipse-platform

Innerhalb dieses Arbeitsverzeichnisses müssen nun die Ordner so angelegt werden, wie sie später auf dem Dateisystem abgebildet werden sollen. Legt man also innerhalb des Ordners eclipse-platform den Ordner bin an und speichert dort Dateien, so werden diese Dateien später nach /bin installiert. Ich lasse den Inhalt des Archivs nach /opt/eclipse installieren:

$ unp eclipse-platform-3.6.2-linux-gtk-x86_64.tar.gz
$ mkdir -p eclipse-platform/opt
$ mv eclipse eclipse-platform/opt/eclipse

Anschließen erstellen wir ein Skript, mit dem wir Eclipse starten können:

$ mkdir -p eclipse-platform/usr/bin
$ nano eclipse-platform/usr/bin/eclipse
$ chmod +x eclipse-platform/usr/bin/eclipse

Das Skript versehen wir mit folgenden Inhalt:

#!/bin/sh
export UBUNTU_MENUPROXY=0
exec /opt/eclipse/eclipse "$@"

Das setzen der Variable UBUNTU_MENUPROXY sorgt dafür, dass Eclipse sein Menü im Fenster und nicht im Unity-Panel anzeigt, weil letzteres noch nicht gut genug mit SWT-Anwendungen funktioniert (Update: Ab Eclipse 3.7 ist die Zeile unnötig, Eclipse zeigt per Default sein Menü im Fenster an). Nicht-Unity-Benutzer können das ignorieren. “$@” bewirkt, dass dem Skript mitgegebene Parameter an Eclipse weitergereicht werden. Nun müssen wir nur noch einen Menüeintrag erstellen, damit wir Eclipse auch grafisch starten können…

$ mkdir -p eclipse-platform/usr/share/applications
$ nano eclipse-platform/usr/share/applications/eclipse.desktop

…und zwar mit diesem Inhalt:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Name=Eclipse
Exec=eclipse
Terminal=false
Icon=/opt/eclipse/icon.xpm
Comment=Eclipse Integrated Development Environment
Categories=Development;IDE;

Nun haben wir also ein Startskript, einen Anwendungsstarter sowie einen Programmordner. Fehlen nur noch Informationen, die das Paket näher beschreiben, damit auch APT was damit anfangen kann.

mkdir eclipse-platform/DEBIAN
nano eclipse-platform/DEBIAN/control

In die control-Datei schmeißen wir das da rein:

Package: eclipse-platform
Version: 3.6.2-1
Architecture: amd64
Maintainer: DeinName
Depends: openjdk-6-jre | sun-java6-jre
Section: devel
Priority: optional
Description: Eclipse IDE, static-linked, minimal plugins.

Die Abhängigkeiten sehen natürlich etwas mager aus, nur Java ist drin, was Eclipse zum Laufen benötigt, aber nicht selbst mitbringt. Alles andere ist bei Eclipse eigentlich dabei und nach den Debian-Richtlinien müsste man eigentlich alles sauber in unabhängige Paketteile aufsplitten, um Redundanzen zu vermeiden, aber das würde das hier zu kompliziert machen. Auf diese Weise sind wir aber jetzt schon fertig und können mit dem verpacken beginnen und die Installation einleiten:

$ fakeroot dpkg -b eclipse-platform eclipse-platform_3.6.2-1_amd64.deb
$ sudo dpkg -i eclipse-platform_3.6.2-1_amd64.deb

Das fakeroot bitte nicht vergessen, sonst werden die Rechte nicht richtig gesetzt!

Eclipse sollte jetzt problemlos und ohne irgendwelche Plugins starten. Damit man jetzt anfangen kann, Eclipse zu benutzen, muss man natürlich erst über Help->Install New Software.. die benötigten Plugins installieren. Zuvor muss jedoch noch die Update-Site von Eclipse hinzugefügt werden, dazu Eclipse starten und zu Window->Preferences->Install/Update->Available Software Sites navigieren und diese URL hinzufügen:

http://download.eclipse.org/releases/helios

Frohes Entwickeln!

About these ads

12 thoughts on “Aktuelles Eclipse selber paketieren

  1. Du hast recht! Eclipse wird wirklich sehr Stiefmütterlich behandelt von den großen Distris. Wenn 3.6 im Februar erschienen wäre, könnte ich es noch verstehen, wenn dieses noch nicht verfügbar ist. ABER: 3.6 erschien schon in Juni 2010 !!!
    Danke für die Anleitung !!!

  2. Es macht aber für einen Distributor nicht wirklich Sinn IDE’s zu paketieren. Ein Entwickler installiert sich sowieso seine bevorzugte IDE in seiner bevorzugten Version und Konfiguration. Sollte ein ernstzunehmender Entwickler das nicht können … naja!
    Mich würde noch interessieren, in welcher Sprache entwickelt Ihr in Eclipse unter Linux, Java – für den Desktop? Java geniest ja nun bei den meisten ein nicht wirklich gutes Ansehen. Dazu kommt noch, dass Java jetzt Oracle gehört und die sind meiner imho nach schlimmer als alle Microsofts, Googles und Facebooks zusammen.

    • Es macht aber für einen Distributor nicht wirklich Sinn IDE’s zu paketieren. Ein Entwickler installiert sich sowieso seine bevorzugte IDE in seiner bevorzugten Version und Konfiguration. Sollte ein ernstzunehmender Entwickler das nicht können … naja!

      Warum kann nicht auch eine IDE einfach zu installieren sein? Ich habe noch nie davon gehört, dass sich Windows- oder Mac-User ihr Visual Studio bzw. XCode selber paketieren. Leicht zugängliche, gut dokumentierte Entwicklertools senken die Einstiegshürde bei jeder Plattform.

      Mich würde noch interessieren, in welcher Sprache entwickelt Ihr in Eclipse unter Linux, Java – für den Desktop?

      Reine Linux-Programme in Java sind relativ selten. Klar gibt es auch viele Java-Desktop-Programme, aber die sind rein platformunabhängig gestrickt und bieten keine Integration in den Desktop und bringen nicht das native Look&Feel, weswegen sich viele Java-Programme wie ein Fremdkörper anfühlen (die GTK+-Variante von Swing ist auch ziemlich schrottig).

      Es gibt aber Bindings wie java-gnome (http://java-gnome.sourceforge.net/), mit denen man z.B GTK+-Anwendungen mit Java erstellen kann, aber die Nachfrage ist da nicht so hoch und es gibt auch nicht so viele Projekte, die das einsetzen (in den Ubuntu-Quellen gibt es bisher kein Paket, welches java-gnome benötigt). Ich kenne mit GNOME Split auch nur ein Programm, welches dies nutzt (http://www.gnome-split.org/).

      Interessanterweise gibt es eine ganze Reihe von C#-Programmen für den Linux-Desktop: Banshee, Tomboy, GNOME Do, gbrainy, Smuxi, Tasque, PdfMod, Pinta usw. und es gibt auch zu vielen Bibliotheken Bindings, sowohl zu GNOME- als auch zu KDE-Bibliotheken. Offenbar scheinen viele OSS-Entwickler lieber eine Microsoft-Sprache als Java verwenden zu wollen, obwohl es von Java mit OpenJDK eine offizielle freie Variante gibt. Mono ist ja nur ein Nachbau vom geschlossenen .NET. Wobei auch Mono in den Paketquellen veraltet ist, in Natty gibt es 2.6, obwohl wir schon 2.8 und 2.10 haben. In Debian Experimental gibt es aber seit kurzem Pakete für 2.10. Bei Mono ist es aber sowieso fraglich, wie es sich nach dem Kauf von Novell und der Gründung von Xamarin weiterentwickelt. schließlich muss der Anschluss an .NET gehalten werden.

      Eine andere interessante Alternative ist Vala, wofür es durch GObject auch massig Bindings gibt, allerdings gibt es bisher wenig Dokumentation und IDE-Support. Gepusht wird ja momentan der Einsatz von Webtechniken auf dem Desktop, GNOME 3 und Qt/QML gehen ja in die Richtung, aber da muss man natürlich erst mal abwarten, wie sich das entwickelt. Und dann wären da natürlich noch C, C++ und Python und das scheinen auch die Sprachen zu sein, die auf meinem Linux/GNOME-Desktop am meisten zum Einsatz kommen. Wobei Python immer noch in einer schwierigen Übergangsphase steckt zwischen 2.x -> 3.x, C++ hingegen ist nicht für jedes Projekt die beste Wahl.

      Hat alles seine Vor- und Nachteile, hängt also ganz vom Projekt ab. :-)

  3. Danke für den Artikel.
    Bei mir funktioniert übrigens das PPA unter Natty wenn ich die Paketquelle auf Maverick anpasse.
    Liebe Grüße, JumpLink

  4. Hallo,

    das hört sich ja einfach an. Geht denn das auch, wenn ich ein Eclipse mit vorinstallierten Plugins nehme?
    Wir wollen bei uns ein lokales Paket-Repository anlegen, in dem vorgefertigte Eclipse-Installationen
    liegen, da alle Entwickler die selbe Umgebung haben sollen.

    Danke, Jörg

    • Klar, du kannst die vorinstallierten Plugins auch selbst bestimmen, musst halt die configuration/features/plugins Ordner in /opt/eclipse richtig befüllen.

  5. Also ich instaliere das überhaupt nicht aus der Paketverwaltung, sondern lade es selber herunter, schiebe es in einen passenden Ordner und erstele entsprechende Links.

    P.S.: Wieso hat man zwei Möglichkeiten, sich über neue Kommentare informieren zu lassen? :D

    • Also ich instaliere das überhaupt nicht aus der Paketverwaltung, sondern lade es selber herunter, schiebe es in einen passenden Ordner und erstele entsprechende Links.

      Geht natürlich auch, aber so kann ich es in einem Zug updaten, deinstallieren, auf andere Rechner übertragen usw.

      Wieso hat man zwei Möglichkeiten, sich über neue Kommentare informieren zu lassen?

      Über E-Mail oder RSS, jeder eben wie er mag. Oder meinst du die beiden Checkboxes unten? Eines davon ist die erwähnte Benachrichtigung über neue Kommentare per E-Mail, beim anderen wird man über neue Artikel per Mail informiert.

      • Ach verdammt, ich sollte auch wenn ich müde bin mal genauer lesen :) Habe bei beiden Checkboxes rausgelesen, dass man über neue Kommentare benachrichtigt wird, weil ich diese Option noch bei keinem anderen WordPress gesehen habe :)

  6. Vielen Dank für die Anleitung!

    Bei mir war es noch nötig die Datei /usr/bin/eclipse per chmod ausführbar zu machen, sonst lies sich Eclipse nicht aus dem Menü starten.

Die Kommentarfunktion ist geschlossen.