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!
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 !!!
Recht hast du, hab ich verwechselt, im Februar 2011 erschien das zweite Service Release.
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.
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.
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.
Danke für den Artikel.
Bei mir funktioniert übrigens das PPA unter Natty wenn ich die Paketquelle auf Maverick anpasse.
Liebe Grüße, JumpLink
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.
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?
Geht natürlich auch, aber so kann ich es in einem Zug updaten, deinstallieren, auf andere Rechner übertragen usw.
Ü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
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.
Ja, das hatte ich vergessen zu erwähnen, habs korrigiert, danke.