Communitygithub.com

Eclipse RCP 4.40: Offline-Engineering

Diagnostizieren, optimieren und warten Sie Eclipse RCP 4.40 (2026-06) Anwendungen mit e3, e4 oder der Kompatibilitätsschicht; SWT/JFace, OSGi, Jobs, Startup, UI-Responsivität und Speicher. Inklusive Offline-Dokumentation.

Was ist Eclipse RCP 4.40: Offline-Engineering?

Dieses Skill befähigt einen KI-Agenten, Eclipse RCP 4.40-Anwendungen vollständig offline zu diagnostizieren, zu optimieren und zu warten. Es verlässt sich auf eine kuratierte, eingebettete Dokumentation (vendor-docs/platform-isv-4.40/) und referenzorientierte Anleitungen (references/), um Webzugriffe oder Cloud-Tools zu vermeiden. Der Agent muss zuerst die Architektur identifizieren (e3, e4 oder Kompatibilitätsschicht), bevor Änderungen vorgenommen werden. Anschließend folgt er einem Optimierungszyklus: Baseline messen, profilieren/diagnostizieren, minimale Änderung umsetzen und erneut messen. Das Skill enthält detaillierte taskorientierte Referenzen zu Performance, e3/e4-APIs, SWT/JFace, OSGi und Build-Prozessen und stellt sicher, dass der Agent keine internen Klassen verwendet oder APIs online abruft. Es ist ideal für Entwickler, die Eclipse RCP-Produkte in einer isolierten, sicherheitskritischen Umgebung warten.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/KeineAhnung1337/skills/tree/HEAD/eclipse-rcp

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht Eclipse RCP 4.40: Offline-Engineering?

Verwenden Sie für dieses Skill niemals Websuche, Netzwerk-Paketdownloads, HTTP-Dokumentation oder reine Cloud-Tools. Der enthaltene Ordner vendor-docs/platform-isv-4.40/ ist ein kuratierter Teil des Eclipse Platform Plug-in Developer Guide und API/Referenz für 4.40: der vollständige Leitfaden sowie ausgewählte e3/e4/SWT/JFace/Jobs-API-Seiten und Erweiterungspunkte. references/ bietet taskorientierte Anleitungen. Ein vollständig offline arbeitender Agent benötigt außerdem ein lokal gehostetes Modell und zwischengespeicherte Build-Abhängigkeiten.

Architektur vor der Bearbeitung identifizieren

  1. Lesen Sie references/index.md und die relevante Aufgabenanleitung. Überprüfen Sie MANIFEST.MF, plugin.xml, *.product, *.feature, Application.e4xmi / Fragmente, Zielplattform, pom.xml oder PDE/Gradle-Build und Java-Baseline.
  2. Stellen Sie fest, ob jeder betroffene Bereich e3-Workbench-APIs, natives e4 oder e3-Kompatibilität auf der e4-Workbench verwendet. e3 verwendet org.eclipse.ui-Erweiterungspunkte, ViewPart/EditorPart, IWorkbench*; e4 verwendet Modelle, Kontexte/DI, Parts/Handler und @*-Lebenszyklusannotationen. Das Vorhandensein von e4-Bundles allein macht ein Produkt nicht zu reinem e4. Übersetzen Sie einen Ansatz nicht ohne Anfrage und Migrationsplan in den anderen.
  3. Identifizieren Sie die genauen Versionen des Ziels. Diese Dokumentation bezieht sich auf Platform 4.40, nicht notwendigerweise auf Versionen von Drittanbieter-Bundles, EMF, GEF, RAP oder das eigene Produkt des Benutzers. Überprüfen Sie für andere APIs die lokale Zielplattform und Quelle/Javadoc; raten Sie niemals Signaturen und verwenden Sie keine internal-Klassen als stabile APIs.

Optimierungszyklus

  1. Erstellen Sie eine beobachtbare Baseline: Umgebung, JVM, Zielplattform, Workspace-Zustand, Kalt-/Warmstart, Operation, Latenz/Heap/UI-Blockade und wiederholbare Messung. Lesen Sie references/performance.md.
  2. Profilen/diagnostizieren Sie zuerst. Erfassen Sie Thread-Dumps für UI-Freezes; untersuchen Sie je nach Symptom CPU-Profile, Allocation/Heap, GC, Logs, Bundle-Aktivierung, Workspace-Jobs und SWT-Ressourcen. Schützen Sie Kundendaten. Priorisieren Sie einen gemessenen Engpass.
  3. Implementieren Sie die kleinste korrekte Änderung unter Beibehaltung von Verhalten und Kompatibilität. Greifen Sie auf SWT-Widgets nur im UI-Thread zu; führen Sie schwere Arbeit in einem Job oder Hintergrundservice aus; behandeln Sie Abbrüche, Dispose-Listener/Ressourcen, erhalten Sie Modell- und DI-Lebenszyklen. Siehe references/e3.md, references/e4.md, references/swt-jface.md, references/osgi-build.md.
  4. Führen Sie Projekttests/Builds nur mit lokal verfügbaren Tools/Abhängigkeiten durch. Messen Sie unter vergleichbaren Bedingungen erneut, testen Sie die e3/e4-Integration falls zutreffend und berichten Sie Vorher-/Nachher-Werte oder sagen Sie, dass eine Verbesserung nicht nachgewiesen wurde. Aktualisieren Sie nicht die Zielplattform, entfernen Sie keine Abhängigkeiten, deaktivieren Sie keine Workbench-Funktionen oder leeren Sie Benutzer-Workspace-Daten als Abkürzung.

Antworten offline finden

  • Beginnen Sie mit references/index.md für genaue lokale Links. Lesen Sie den Originalleitfaden unter vendor-docs/platform-isv-4.40/guide/ und verfügbare API-Seiten unter vendor-docs/platform-isv-4.40/reference/api/ mit normaler Dateisystem-Suche; verwenden Sie die enthaltenen Erweiterungspunkt-Dokumente und genauen 4.40-Javadocs für Signaturen, sofern vorhanden.
  • Die kompakte Edition enthält viele API-Klassen und Erweiterungspunkte nicht. Links innerhalb von vendor-HTML können auf fehlende Dateien verweisen. Wenn eine genaue Seite fehlt, konsultieren Sie die Dokumentation oder Quellen des offline verfügbaren 4.40-SDK/Zielplattform; erfinden Sie keine API und rufen Sie diese nicht online ab.
  • Behandeln Sie Beispielschnipsel nicht als vollständige Plugin/Projektvorlagen: Überprüfen Sie das Zielmanifest und die Erweiterungsschemata. Verifizieren Sie für unsichere APIs die tatsächliche 4.40-API-Seite und das Abhängigkeits-Bundle oder geben Sie explizit die Unsicherheit an.
  • Die Vendor-Dateien enthalten about.html, notices.html und Lizenz. Siehe README.md für Herkunft und Offline-Einrichtung. Ihre Online-Links sind historische Referenzen, keine Abhängigkeiten.

Individual skills in this repo

This repo contains 2 individual skills — each has its own dedicated page.

Verwandte Skills