| name | eclipse-plugin-development |
| description | Guidance for implementing and modifying Eclipse plugin, RCP, and OSGi-based code while preserving target-platform and JDK compatibility. |
Eclipse Plugin Development
Use this skill when working on tasks related to:
- Eclipse plugins
- Eclipse RCP applications
- OSGi bundles
- extension points
- plugin metadata
- target-platform constrained implementation
- PDE / Tycho based plugin projects
- SWT / JFace / Eclipse UI integration
Goal
Produce changes that fit Eclipse plugin development conventions and remain compatible with:
- the repository's minimum supported Eclipse target-platform
- the repository's minimum supported JDK version
Working Approach
1. Start from repository constraints
Before suggesting implementation details, first align with the repository's actual setup if it can be determined from the codebase, build files, or target-platform:
- minimum supported Eclipse release
- target-platform definition
- minimum supported JDK / execution environment
- Tycho / Maven / PDE build structure
- current plugin and module layout
- existing UI framework usage such as SWT, JFace, e4, commands, handlers, views, editors, or wizards
If exact compatibility boundaries are unclear, prefer the most conservative implementation that is likely to work on the currently configured minimum versions.
2. Follow Eclipse-native architecture
Prefer solutions that align with existing Eclipse and OSGi patterns already used by the repository, such as:
- extension points
- commands and handlers
- views, editors, dialogs, and wizards
- preference pages and preference stores
- background jobs and progress monitors
- OSGi services or declarative services if already present
- Eclipse workspace and resource APIs where appropriate
Do not replace Eclipse-native mechanisms with generic alternatives unless explicitly requested.
3. Keep plugin metadata synchronized
When implementation changes affect plugin wiring, runtime behavior, packaging, or dependencies, check whether related metadata must also be updated.
Common files to inspect:
META-INF/MANIFEST.MFplugin.xmlfragment.xmlbuild.propertiesfeature.xmlcategory.xml.target filespom.xml- product configuration files
- service component descriptors
- preference initializer classes
- plugin activator or lifecycle related files
Examples:
- adding a handler, menu contribution, command, view, editor, or preference page may require
plugin.xml
- adding or removing bundle dependencies may require
MANIFEST.MF
- adding packaged resources may require
build.properties
- changing installable content may require
feature.xml, category.xml, or p2-related configuration
- changing platform assumptions may require updates to
.target files or Tycho configuration
4. Prefer public APIs
Use stable public Eclipse APIs whenever possible.
Avoid packages containing .internal. unless:
- the repository already intentionally depends on them, and
- no suitable public API exists
If internal API use is unavoidable, explicitly call out the compatibility and maintenance risk.
5. Respect UI and threading constraints
For SWT/JFace/Eclipse UI work:
- access UI widgets on the UI thread
- avoid blocking the UI thread with long-running work
- use background jobs for expensive operations
- report progress when appropriate
- keep handlers, dialogs, wizards, views, and editors consistent with existing repository patterns
Do not introduce Swing, JavaFX, or browser/web UI approaches unless they are already part of the repository or explicitly requested.
6. Respect internationalization practices
If the repository externalizes user-facing strings:
- do not hardcode visible UI text
- update the relevant messages or properties files
- follow the existing NLS pattern consistently
7. Use Eclipse-friendly error handling
When appropriate, prefer patterns already common in Eclipse plugin codebases, such as:
IStatusStatusMultiStatusCoreException
Use the repository's existing logging and status reporting style where available.
Avoid printStackTrace and avoid silent failure paths.
8. Preserve stable IDs and contracts
Unless explicitly requested, do not rename or break the stability of:
- plugin IDs
- bundle symbolic names
- extension point IDs
- command IDs
- handler IDs
- view IDs
- editor IDs
- preference keys
- marker IDs
- builder IDs
- nature IDs
- exported packages
- public APIs
Backward compatibility is especially important for plugin integrations and workspace metadata.
9. Use version-safe Java
Do not use Java language features, standard library APIs, or build assumptions beyond the repository's minimum supported JDK.
If there is any doubt, prefer the older and more broadly compatible implementation.
Be especially careful with features that are version-sensitive, for example:
- records
- sealed classes
- pattern matching
- enhanced switch syntax
- text blocks
- virtual threads
- preview features
- newer collection APIs
10. Keep tests aligned with plugin realities
When adding or updating tests:
- follow the repository's existing test structure
- stay consistent with current PDE / Tycho / JUnit / SWTBot usage if present
- keep tests compatible with the minimum supported platform and JDK
- avoid fragile UI timing assumptions
- avoid tests that depend on environment-specific state unless the repository already uses such patterns intentionally
Eclipse Plugin Task Checklist
Before considering a task complete, check whether the change should also verify or update:
- API compatibility with the minimum Eclipse target-platform
- API compatibility with the minimum JDK
META-INF/MANIFEST.MFplugin.xmlbuild.properties- feature / p2 / category metadata
.target or Tycho/Maven configuration- externalized strings and message bundles
- background job vs UI thread behavior
- logging and error reporting consistency
- public IDs and extension contracts
Output Expectations
When proposing or implementing changes for Eclipse plugin tasks, include relevant notes about:
- why the solution is expected to work with the minimum target-platform
- why the solution is expected to work with the minimum JDK
- which plugin metadata files may also need to be updated
- any compatibility risk introduced by API or dependency choices
