Auf so ein "Metapacket" hab ich schon lange gewartet.
Die Grundinstallation von rund 34Mb ist schnell downgeloadet und anschließend über den Updater kann man genau einstellen was man haben will. (340Mb nach downloaden und entpacken von allen Tools)
Also Eclipse is für mich die NR-1 bei den Entwicklungsumgebungen!
Dieses Meta-Paket ist sicherlich nicht verkehrt. Allerdings finde ich den Weg den man teilweise bei Debian oder Ubuntu geht auch nicht schlecht, wo man Teile mit ins Paketsystem reinnimmt. Ist zwar nicht alles drinnen aber CDT oder so auf jedenfall. Das erspart einem wenigstends teilweise die Bastelei die man sonst so hat. Würde mir gerne manchmal ein Metapaket wünschen wo Eclipse, CDT, Subclipse, Doxygen oder anders gesagt, alle Dinge die für C/C++ Entwicklung interessant wären zusammenhängend wären.
Gerade bei Eclipse ist zunehmend das Problem die Plugins zu finden weil es einfach zuviele gibt Würde mir wünschen das man vielleicht in Zukunft Plugins etwas zentraler verwaltet und auch dann innerhalb von Eclipse diese auswählen kann.
Schau dir mal http://yoxos.com/ondemand/ an, da kannst du dir alle möglichen Plugins selbst zusammenstellen und bekommst am Ende ein entsprechendes zip File zum Download.
Ich persönlich finde den Weg, den Debian und Ubuntu gehen verkehrt.
Es ist okay, das Programm an sich bequem als deb installierbar zu machen, aber zusätzlich noch nen Wust an Plugins zum Download anzubieten finde ich hier genauso sinnlos, wie bei anderen Programmen, z.B. Bibelversionen bei GnomeSword oder Extensions für Firefox.
Der einzige Grund der mir dafür einfällt, ist bei der nächsten Presseerklärung werbewirksam von 24.000 Paketen oder so zu reden, die zur Verfügung stehen unter Debian/Ubuntu oder so.
Sobald ein Programm ein eigenes Plugin-Installationssystem hat, und ein Plugin-Repository das so umfangreich ist wie z.B. bei Eclipse, sollte man es einfach solch einem dem User und dem eingebauten System überlassen Plugins zu installieren.
Zum einen ist es unnötiger Aufwand, für ein Eclipse-Plugin-"Paket" nochmal ein Debian-Paket zu erstellen, zum zweiten ist z.B. bei der Python Entwicklungsumgebung für Eclipse, PyDev, die Aktivität so hoch, das man niemals auf dem aktuellen Stand bleiben kann mit den Paketen - man installiert also per apt PyDev und dann muss man es gleich wieder updaten - dann wiederrum hat man aber das problem, das man Eclipse ja nicht als root ausgeführt hat - das wiederrum ergibt dann das Problem, das Plugins, die per apt installiert wurden, welche dann natürlich auch nicht ins Homeverzeichnis kopiert wurden, für den User mit dem Eclipse gestartet wurde, nur lesbar zugegriffen werden kann.
Somit kann die per apt installierte Plugins auch nur per apt wieder updaten. Und speziell bei Debian wissen wir ja, wie lange man auf ein Update warten darf.
Also: Bei Software mit interner Plugin-Verwaltung nur das Programm installieren und das mit den Plugins dem dafür vorgesehenen Tool überlassen.
"Sobald ein Programm ein eigenes Plugin-Installationssystem hat, und ein Plugin-Repository das so umfangreich ist wie z.B. bei Eclipse, sollte man es einfach solch einem dem User und dem eingebauten System überlassen Plugins zu installieren."
Dem User? Nicht vielleicht jedem der 20 User, die u.U. an einer Maschine arbeiten? Jeder der 20 User *muss* regelmäßig (d.h. sobald der Admin eine inkompatible Version eingespielt hat - passiert beim Firefox dauernd) neue Plugins für Eclipse runterladen, neue Plugins für den Firefox runterladen, neue Plugins für ... runterladen. Findest du das effizient?
"Und speziell bei Debian wissen wir ja, wie lange man auf ein Update warten darf."
Viele der Programme, die ich verwende, sind am Release-Tag bereits in Incoming (d.h. am nächsten Tag in Unstable), teilweise sogar schon *vor* dem offiziellen Announcement (z.B. Wesnoth).
Sobald der User seine individuellen Plugins gewählt hat - da ja jeder Entwickler seine eigenen Präferenzen etc. hat - kann man anwählen, das Updates automatisch geladen werden.
Mich würde außerdem gerne interessieren was du mit Bastelei meinst? Ich kenne das nur so, URL im Plugin-Wizard angeben, Plugin installieren, und dann an seine Bedürfnisse anpassen.
Das was du suchst gibt es schon lange, nur leider ein wenig versteckt auf der Hauptseite zu finden, in Form eines Banners ;) http://www.eclipseplugincentral.com/ Dort kannst du bequem wie etwa bei Sourceforge in der Software Map, die jeweiligen Plugins durchforsten.
Außerdem gibts ja gewissen Quasi-Standards: - CDT für C - Subclipse für die Versionskontrolle per SVN - PyDev & die PyDev Extensions für Python - EPIC für Perl (nicht mit der gleich abgekürtzen Website verwechseln von der ich vorhin geredet habe) - JSclipse für JavaScript und AJAX Toolkits wie Dojo - PHPeclipse für PHP bzw. PHP Development Studio das auch gleich folgendes enthält: - Eclipse Web Tools für HTML CSS etc.
Wenn man mal bei ner gewissen Anzahl von Sprachen und Technologien angelangt ist, mit der man zu arbeiten hat, ist Eclipse einfach nur noch praktisch Man muss sich nicht von der Oberfläche umgewöhnen, und das mit dem Speichermonster rückt auch in den Hintergrund wenn man sich überlegt, das man sonst für alles sein eigenes Programm offen hätte - Quanta für die Webentwicklung, Anjuta für C, SPE für Python, etc.
Mit Bastelei meine ich genau das... Projektseite suchen und raufgehen, die URL suchen und bei Eclipse eintragen... Nach neuen Features suchen usw. Bei der Masse der Plugins ist das einfach nicht sonderlich gut gelöst. Dafür wäre ein Update-Manager innerhalb Eclipse der die einzelnen Plugins (mit einer kurzen Beschreibung) und einer Auswahlmöglichkeit ("Installieren") einfach schöner. Auch könnte man dort "Meta-Pakete" gleich als Auswahl zusammenfassen. Z.b. "C/C++ Entwicklung - Minimal/Full" wo dann halt z.B. auch Subclipse,Doxygen, CDT mit drinnen sind. Genauso das bei Webentwicklung gleich PHP und Webtools mit installiert werden.
Wie auch immer... Momentan finde ich das noch nicht optimal gelöst.
>Mit Bastelei meine ich genau das... Projektseite suchen und raufgehen, die URL suchen und bei Eclipse eintragen... Nach >neuen Features suchen usw. Bei der Masse der Plugins ist das einfach nicht sonderlich gut gelöst. Dafür wäre ein >Update-Manager innerhalb Eclipse der die einzelnen Plugins (mit einer kurzen Beschreibung) und einer Auswahlmöglichkeit >("Installieren") einfach schöner.
Was du willst ist Callisto, und wenn ich mich nicht täusche ist dies eine Meldung über Callisto. Hast du die Meldung überhaupt gelesen? Oder einfach kommentiert?
Callisto ist schon was anderes als das was ich meinte, hast du meinen Kommentar überhaupt gelesen oder einfach nur kommentiert ;)
Callisto ist eine Art Meta-Distribution von Eclipse die ca. 10 Unterprojekte zusammenführen will und diese auch synchronisieren, soweit das sie zur gleichen Zeit released werden können. Das was ich meinte ist eine andere Art der Auswahlmöglichkeit/Übersicht von allen verfügbaren Plugins innerhalb von Eclipse, sodaß man z.B. sich nicht erst die Quell-Urls besorgen muss usw.
Doch, dafür gibt ja die Distributionen - ob das nun eine Linux oder Eclipse ist. Hast Du mal das von Earthwings weiter oben genannte ich-stelle-mir-mein-Eclipse-als-ZIP-zusammen angesehen?
Dieser "Zip-Zusammensteller" ist sehr gut. Habs kurz durchgespielt und der erkennt auch Abhängigkeiten (wollte zumindest bei Sublclipse noch was zusätzliches mitnehmen).
Nach langer Zeit wollte ich am Wochenende wieder einen Versuch mit Eclipse wagen und dachte, dass Callisto da doch sehr einfach wäre! Ich habe die Anweisungen abgearbeitet und eclipse-3.2 installiert (XP) und versuchte dann die restlichen Funktionen (features/Plugins?) per Update-Manager herunter zu laden. Das scheiterte an einigen Stellen weil z.B org.eclipse.gef oder org.eclipse.emf vorausgesetzt wurde. Somit begann die Sucherei für mich (Anfänger!). Nach dem umschiffen dieser Hürden fehlt mir nur noch org.eclipse.birt.core um den Rest installieren zu können, wobei die hiervon abhängenden Dinge für mich nicht so wichtig sind.
Was ich aber jetzt noch nicht gelöst bekommen habe ist das Umstellen der Sprache auf Deutsch. Ich habe die Sprachfiles von der download-Seite ins Verzeichnis entpackt (NLpack1_FeatureOverlay-eclipse-SDK-3.1.1.zip) diese haben immer noch die Version 3.1.1 und werden nicht erkannt. Auch nicht per cmd als eclipse -nl de oder de_DE angesteuert.
Habe ich da etwas übersehen? Wie sind so die Installationserfahrungen von anderen/andere OS?
Ich habe auf meinem LINUX-Rechner eclipse 3.1.1 installiert und das lief eigentlich sehr problemlos. Hier macht mir Callisto also mehr Arbeit als die "Handinstallation". Bringt der Update auf Callisto hier etwas?
Die Sprachendateien von Eclipse 3.1.1 wirst Du nicht für Eclipse 3.2 verwenden können. Bestimmt wird aber auch hierfür in absehbarer Zeit eine Sprachenpaket herausgegeben.
Das mit den "org.eclipse.gef"- und "org.eclipse.emf"-Abhängigkeiten ist in dem Moment kein Problem, wenn Du den Knopf "Select Required" auf der rechten Seite findest, der die nötigen Pakete automatisch auswählt. EMF und GEF stehen nämlich auch in der Callisto-Liste mit drin. Probiere das am besten nochmal, falls Du es nicht schon rausgefunden hast.
Die Grundinstallation von rund 34Mb ist schnell downgeloadet und anschließend über den Updater kann man genau einstellen was man haben will. (340Mb nach downloaden und entpacken von allen Tools)
Also Eclipse is für mich die NR-1 bei den Entwicklungsumgebungen!
Eclipse ist mehr Betriebssystem als Entwicklungsumgebung.
fs
sogar einen mp3-player
>Also Eclipse is für mich die NR-1 bei den Entwicklungsumgebungen!
1. IntelliJ IDEA (EAP Version)
2. Netbeans
3. JDeveloper
...
x. Eclipse == Pain-In-The-Ass-Software
-J
Würde mir gerne manchmal ein Metapaket wünschen wo Eclipse, CDT, Subclipse, Doxygen oder anders gesagt, alle Dinge die für C/C++ Entwicklung interessant wären zusammenhängend wären.
Gerade bei Eclipse ist zunehmend das Problem die Plugins zu finden weil es einfach zuviele gibt
Würde mir wünschen das man vielleicht in Zukunft Plugins etwas zentraler verwaltet und auch dann innerhalb von Eclipse diese auswählen kann.
Es ist okay, das Programm an sich bequem als deb installierbar zu machen, aber zusätzlich noch nen Wust an Plugins zum Download anzubieten finde ich hier genauso sinnlos, wie bei anderen Programmen, z.B. Bibelversionen bei GnomeSword oder Extensions für Firefox.
Der einzige Grund der mir dafür einfällt, ist bei der nächsten Presseerklärung werbewirksam von 24.000 Paketen oder so zu reden, die zur Verfügung stehen unter Debian/Ubuntu oder so.
Sobald ein Programm ein eigenes Plugin-Installationssystem hat, und ein Plugin-Repository das so umfangreich ist wie z.B. bei Eclipse, sollte man es einfach solch einem dem User und dem eingebauten System überlassen Plugins zu installieren.
Zum einen ist es unnötiger Aufwand, für ein Eclipse-Plugin-"Paket" nochmal ein Debian-Paket zu erstellen, zum zweiten ist z.B. bei der Python Entwicklungsumgebung für Eclipse, PyDev, die Aktivität so hoch, das man niemals auf dem aktuellen Stand bleiben kann mit den Paketen - man installiert also per apt PyDev und dann muss man es gleich wieder updaten - dann wiederrum hat man aber das problem, das man Eclipse ja nicht als root ausgeführt hat - das wiederrum ergibt dann das Problem, das Plugins, die per apt installiert wurden, welche dann natürlich auch nicht ins Homeverzeichnis kopiert wurden, für den User mit dem Eclipse gestartet wurde, nur lesbar zugegriffen werden kann.
Somit kann die per apt installierte Plugins auch nur per apt wieder updaten. Und speziell bei Debian wissen wir ja, wie lange man auf ein Update warten darf.
Also: Bei Software mit interner Plugin-Verwaltung nur das Programm installieren und das mit den Plugins dem dafür vorgesehenen Tool überlassen.
Dem User? Nicht vielleicht jedem der 20 User, die u.U. an einer Maschine arbeiten? Jeder der 20 User *muss* regelmäßig (d.h. sobald der Admin eine inkompatible Version eingespielt hat - passiert beim Firefox dauernd) neue Plugins für Eclipse runterladen, neue Plugins für den Firefox runterladen, neue Plugins für ... runterladen. Findest du das effizient?
"Und speziell bei Debian wissen wir ja, wie lange man auf ein Update warten darf."
Viele der Programme, die ich verwende, sind am Release-Tag bereits in Incoming (d.h. am nächsten Tag in Unstable), teilweise sogar schon *vor* dem offiziellen Announcement (z.B. Wesnoth).
Eckhart
Ja ich finde das äußerst effizient.
Ich kenne das nur so, URL im Plugin-Wizard angeben, Plugin installieren, und dann an seine Bedürfnisse anpassen.
Das was du suchst gibt es schon lange, nur leider ein wenig versteckt auf der Hauptseite zu finden, in Form eines Banners ;)
http://www.eclipseplugincentral.com/
Dort kannst du bequem wie etwa bei Sourceforge in der Software Map, die jeweiligen Plugins durchforsten.
Außerdem gibts ja gewissen Quasi-Standards:
- CDT für C
- Subclipse für die Versionskontrolle per SVN
- PyDev & die PyDev Extensions für Python
- EPIC für Perl (nicht mit der gleich abgekürtzen Website verwechseln von der ich vorhin geredet habe)
- JSclipse für JavaScript und AJAX Toolkits wie Dojo
- PHPeclipse für PHP bzw. PHP Development Studio das auch gleich folgendes enthält:
- Eclipse Web Tools für HTML CSS etc.
Wenn man mal bei ner gewissen Anzahl von Sprachen und Technologien angelangt ist, mit der man zu arbeiten hat, ist Eclipse einfach nur noch praktisch
Man muss sich nicht von der Oberfläche umgewöhnen, und das mit dem Speichermonster rückt auch in den Hintergrund wenn man sich überlegt, das man sonst für alles sein eigenes Programm offen hätte - Quanta für die Webentwicklung, Anjuta für C, SPE für Python, etc.
Auch könnte man dort "Meta-Pakete" gleich als Auswahl zusammenfassen. Z.b. "C/C++ Entwicklung - Minimal/Full" wo dann halt z.B. auch Subclipse,Doxygen, CDT mit drinnen sind. Genauso das bei Webentwicklung gleich PHP und Webtools mit installiert werden.
Wie auch immer... Momentan finde ich das noch nicht optimal gelöst.
Was du willst ist Callisto, und wenn ich mich nicht täusche ist dies eine Meldung über Callisto.
Hast du die Meldung überhaupt gelesen? Oder einfach kommentiert?
Callisto ist eine Art Meta-Distribution von Eclipse die ca. 10 Unterprojekte zusammenführen will und diese auch synchronisieren, soweit das sie zur gleichen Zeit released werden können. Das was ich meinte ist eine andere Art der Auswahlmöglichkeit/Übersicht von allen verfügbaren Plugins innerhalb von Eclipse, sodaß man z.B. sich nicht erst die Quell-Urls besorgen muss usw.
Hast Du mal das von Earthwings weiter oben genannte ich-stelle-mir-mein-Eclipse-als-ZIP-zusammen angesehen?
Was ich aber jetzt noch nicht gelöst bekommen habe ist das Umstellen der Sprache auf Deutsch. Ich habe die Sprachfiles von der download-Seite ins Verzeichnis entpackt (NLpack1_FeatureOverlay-eclipse-SDK-3.1.1.zip) diese haben immer noch die Version 3.1.1 und werden nicht erkannt. Auch nicht per cmd als eclipse -nl de oder de_DE angesteuert.
Habe ich da etwas übersehen? Wie sind so die Installationserfahrungen von anderen/andere OS?
Ich habe auf meinem LINUX-Rechner eclipse 3.1.1 installiert und das lief eigentlich sehr problemlos. Hier macht mir Callisto also mehr Arbeit als die "Handinstallation". Bringt der Update auf Callisto hier etwas?
Beste Grüße
Harald
Das mit den "org.eclipse.gef"- und "org.eclipse.emf"-Abhängigkeiten ist in dem Moment kein Problem, wenn Du den Knopf "Select Required" auf der rechten Seite findest, der die nötigen Pakete automatisch auswählt. EMF und GEF stehen nämlich auch in der Callisto-Liste mit drin. Probiere das am besten nochmal, falls Du es nicht schon rausgefunden hast.