Skip to content

Commit 9a5d5bd

Browse files
unknowIfGuestInDreamunknowIfGuestInDream
committed
ci: Improve copilot
1 parent d30c877 commit 9a5d5bd

5 files changed

Lines changed: 569 additions & 0 deletions

File tree

‎.github/copilot-instructions.md‎

Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# Copilot Instructions
2+
3+
## General Working Rules
4+
5+
This repository is used for Eclipse plugin related development.
6+
When generating or modifying code, configuration, tests, build files, or documentation, always follow these rules.
7+
8+
### 1. Compatibility first
9+
- Always prioritize compatibility with the repository's minimum supported Eclipse target-platform.
10+
- Always prioritize compatibility with the repository's minimum supported JDK version.
11+
- Do not assume the latest Eclipse APIs or latest Java language features are available.
12+
- If compatibility is unclear, prefer the more conservative implementation.
13+
14+
### 2. Follow the existing repository style
15+
- Reuse the existing architecture, naming, module boundaries, package structure, and file organization.
16+
- Prefer the frameworks and implementation patterns already used in the repository.
17+
- Avoid introducing new frameworks, libraries, or architectural styles unless explicitly requested.
18+
19+
### 3. Keep changes minimal and focused
20+
- Make the smallest safe change that solves the task.
21+
- Avoid unrelated refactoring, broad renaming, or formatting-only edits across unrelated files.
22+
- Preserve backward compatibility wherever possible.
23+
24+
### 4. Commit messages
25+
Use Angular Commit Convention for all suggested commit messages.
26+
27+
Examples:
28+
- `feat(ui): add preference page`
29+
- `fix(core): avoid null pointer on startup`
30+
- `docs(readme): clarify installation steps`
31+
- `build(target-platform): align dependency constraints`
32+
- `refactor(service): simplify project resolver`
33+
- `test(ui): stabilize wizard interaction test`
34+
- `ci: Improve github workflow`
35+
- `chore: clean up unused scripts`
36+
- `style: format code with prettier`
37+
38+
### 5. Dependency discipline
39+
- Do not add dependencies unless necessary.
40+
- Any new dependency must be compatible with the repository's minimum supported Eclipse target-platform and minimum supported JDK.
41+
- Prefer stable, public, well-supported APIs over internal or experimental ones.
42+
43+
### 6. Explain important assumptions
44+
When making non-trivial changes:
45+
- state important assumptions clearly
46+
- mention compatibility considerations
47+
- mention related metadata or configuration files that may also need updates
48+
- call out risks if internal APIs or version-sensitive features are involved
49+
50+
## Skill routing
51+
When a task involves Eclipse plugin specific work, also apply the appropriate skill guidance from:
52+
53+
- `.github/skills/eclipse-plugin-development/SKILLS.md`
54+
- `.github/skills/tycho-build-and-target-platform/SKILLS.md`
55+
- `.github/skills/eclipse-ui-development/SKILLS.md`
56+
- `.github/skills/eclipse-plugin-testing/SKILLS.md`
57+
58+
### Skill selection guidance
59+
- Use `eclipse-plugin-development` for general plugin, OSGi, extension-point, manifest, lifecycle, and integration work.
60+
- Use `tycho-build-and-target-platform` for target-platform, Tycho, p2, feature, category, dependency resolution, and build alignment tasks.
61+
- Use `eclipse-ui-development` for SWT, JFace, commands, handlers, views, editors, dialogs, wizards, preference pages, and workbench UI tasks.
62+
- Use `eclipse-plugin-testing` for JUnit, PDE, Tycho test execution, SWTBot, UI test stability, and plugin/runtime test structure.

‎.github/skills/eclipse-plugin-development/SKILLS.md‎

Lines changed: 171 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,171 @@
1+
---
2+
name: eclipse-plugin-development
3+
description: Guidance for implementing and modifying Eclipse plugin, RCP, and OSGi-based code while preserving target-platform and JDK compatibility.
4+
---
5+
6+
# Eclipse Plugin Development
7+
8+
Use this skill when working on tasks related to:
9+
10+
- Eclipse plugins
11+
- Eclipse RCP applications
12+
- OSGi bundles
13+
- extension points
14+
- plugin metadata
15+
- target-platform constrained implementation
16+
- PDE / Tycho based plugin projects
17+
- SWT / JFace / Eclipse UI integration
18+
19+
## Goal
20+
21+
Produce changes that fit Eclipse plugin development conventions and remain compatible with:
22+
- the repository's minimum supported Eclipse target-platform
23+
- the repository's minimum supported JDK version
24+
25+
## Working Approach
26+
27+
### 1. Start from repository constraints
28+
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:
29+
- minimum supported Eclipse release
30+
- target-platform definition
31+
- minimum supported JDK / execution environment
32+
- Tycho / Maven / PDE build structure
33+
- current plugin and module layout
34+
- existing UI framework usage such as SWT, JFace, e4, commands, handlers, views, editors, or wizards
35+
36+
If exact compatibility boundaries are unclear, prefer the most conservative implementation that is likely to work on the currently configured minimum versions.
37+
38+
### 2. Follow Eclipse-native architecture
39+
Prefer solutions that align with existing Eclipse and OSGi patterns already used by the repository, such as:
40+
- extension points
41+
- commands and handlers
42+
- views, editors, dialogs, and wizards
43+
- preference pages and preference stores
44+
- background jobs and progress monitors
45+
- OSGi services or declarative services if already present
46+
- Eclipse workspace and resource APIs where appropriate
47+
48+
Do not replace Eclipse-native mechanisms with generic alternatives unless explicitly requested.
49+
50+
### 3. Keep plugin metadata synchronized
51+
When implementation changes affect plugin wiring, runtime behavior, packaging, or dependencies, check whether related metadata must also be updated.
52+
53+
Common files to inspect:
54+
- `META-INF/MANIFEST.MF`
55+
- `plugin.xml`
56+
- `fragment.xml`
57+
- `build.properties`
58+
- `feature.xml`
59+
- `category.xml`
60+
- `.target` files
61+
- `pom.xml`
62+
- product configuration files
63+
- service component descriptors
64+
- preference initializer classes
65+
- plugin activator or lifecycle related files
66+
67+
Examples:
68+
- adding a handler, menu contribution, command, view, editor, or preference page may require `plugin.xml`
69+
- adding or removing bundle dependencies may require `MANIFEST.MF`
70+
- adding packaged resources may require `build.properties`
71+
- changing installable content may require `feature.xml`, `category.xml`, or p2-related configuration
72+
- changing platform assumptions may require updates to `.target` files or Tycho configuration
73+
74+
### 4. Prefer public APIs
75+
Use stable public Eclipse APIs whenever possible.
76+
77+
Avoid packages containing `.internal.` unless:
78+
- the repository already intentionally depends on them, and
79+
- no suitable public API exists
80+
81+
If internal API use is unavoidable, explicitly call out the compatibility and maintenance risk.
82+
83+
### 5. Respect UI and threading constraints
84+
For SWT/JFace/Eclipse UI work:
85+
- access UI widgets on the UI thread
86+
- avoid blocking the UI thread with long-running work
87+
- use background jobs for expensive operations
88+
- report progress when appropriate
89+
- keep handlers, dialogs, wizards, views, and editors consistent with existing repository patterns
90+
91+
Do not introduce Swing, JavaFX, or browser/web UI approaches unless they are already part of the repository or explicitly requested.
92+
93+
### 6. Respect internationalization practices
94+
If the repository externalizes user-facing strings:
95+
- do not hardcode visible UI text
96+
- update the relevant messages or properties files
97+
- follow the existing NLS pattern consistently
98+
99+
### 7. Use Eclipse-friendly error handling
100+
When appropriate, prefer patterns already common in Eclipse plugin codebases, such as:
101+
- `IStatus`
102+
- `Status`
103+
- `MultiStatus`
104+
- `CoreException`
105+
106+
Use the repository's existing logging and status reporting style where available.
107+
Avoid `printStackTrace` and avoid silent failure paths.
108+
109+
### 8. Preserve stable IDs and contracts
110+
Unless explicitly requested, do not rename or break the stability of:
111+
- plugin IDs
112+
- bundle symbolic names
113+
- extension point IDs
114+
- command IDs
115+
- handler IDs
116+
- view IDs
117+
- editor IDs
118+
- preference keys
119+
- marker IDs
120+
- builder IDs
121+
- nature IDs
122+
- exported packages
123+
- public APIs
124+
125+
Backward compatibility is especially important for plugin integrations and workspace metadata.
126+
127+
### 9. Use version-safe Java
128+
Do not use Java language features, standard library APIs, or build assumptions beyond the repository's minimum supported JDK.
129+
130+
If there is any doubt, prefer the older and more broadly compatible implementation.
131+
132+
Be especially careful with features that are version-sensitive, for example:
133+
- records
134+
- sealed classes
135+
- pattern matching
136+
- enhanced switch syntax
137+
- text blocks
138+
- virtual threads
139+
- preview features
140+
- newer collection APIs
141+
142+
### 10. Keep tests aligned with plugin realities
143+
When adding or updating tests:
144+
- follow the repository's existing test structure
145+
- stay consistent with current PDE / Tycho / JUnit / SWTBot usage if present
146+
- keep tests compatible with the minimum supported platform and JDK
147+
- avoid fragile UI timing assumptions
148+
- avoid tests that depend on environment-specific state unless the repository already uses such patterns intentionally
149+
150+
## Eclipse Plugin Task Checklist
151+
152+
Before considering a task complete, check whether the change should also verify or update:
153+
- API compatibility with the minimum Eclipse target-platform
154+
- API compatibility with the minimum JDK
155+
- `META-INF/MANIFEST.MF`
156+
- `plugin.xml`
157+
- `build.properties`
158+
- feature / p2 / category metadata
159+
- `.target` or Tycho/Maven configuration
160+
- externalized strings and message bundles
161+
- background job vs UI thread behavior
162+
- logging and error reporting consistency
163+
- public IDs and extension contracts
164+
165+
## Output Expectations
166+
167+
When proposing or implementing changes for Eclipse plugin tasks, include relevant notes about:
168+
- why the solution is expected to work with the minimum target-platform
169+
- why the solution is expected to work with the minimum JDK
170+
- which plugin metadata files may also need to be updated
171+
- any compatibility risk introduced by API or dependency choices

‎.github/skills/eclipse-plugin-testing/SKILLS.md‎

Lines changed: 110 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,110 @@
1+
---
2+
name: eclipse-plugin-testing
3+
description: Guidance for testing Eclipse plugins with JUnit, PDE, Tycho, SWTBot, runtime tests, and UI stability considerations.
4+
---
5+
6+
# Eclipse Plugin Testing
7+
8+
Use this skill when working on tasks related to:
9+
- JUnit tests for plugin code
10+
- PDE or runtime tests
11+
- Tycho test execution
12+
- SWTBot tests
13+
- UI interaction tests
14+
- plugin integration tests
15+
- test stability for Eclipse-based code
16+
17+
## Goal
18+
19+
Add or modify tests that are reliable, maintainable, and compatible with the repository's minimum supported Eclipse target-platform and JDK.
20+
21+
## Working Approach
22+
23+
### 1. Follow the repository's existing test structure
24+
Before adding tests, determine what the repository already uses:
25+
- plain JUnit unit tests
26+
- plugin/runtime tests
27+
- PDE test setup
28+
- Tycho surefire or failsafe style execution
29+
- SWTBot UI tests
30+
- test fragment or dedicated test bundles
31+
- headless vs UI-enabled test modules
32+
33+
Prefer the existing testing approach over introducing a new one.
34+
35+
### 2. Choose the lightest valid test level
36+
Prefer the simplest test type that can verify the behavior correctly:
37+
- use unit tests for isolated logic
38+
- use plugin/runtime tests when Eclipse runtime integration is required
39+
- use SWTBot or UI tests only when real UI behavior must be verified
40+
41+
Avoid solving purely non-UI logic with expensive UI-level tests.
42+
43+
### 3. Keep tests compatible with target-platform and JDK constraints
44+
Test code must also respect:
45+
- the minimum supported Eclipse target-platform
46+
- the minimum supported JDK
47+
- the repository's actual test runtime setup
48+
49+
Do not use newer test libraries, APIs, or Java features that exceed the current project baseline unless explicitly requested.
50+
51+
### 4. Avoid fragile UI tests
52+
For SWTBot or other UI-driven tests:
53+
- avoid unnecessary sleeps
54+
- prefer explicit waiting conditions
55+
- keep interactions deterministic
56+
- reduce timing sensitivity
57+
- avoid dependence on screen layout or environment-specific focus behavior where possible
58+
59+
### 5. Respect plugin/runtime realities
60+
For Eclipse plugin tests, be careful about:
61+
- workspace state
62+
- active workbench state
63+
- UI thread constraints
64+
- bundle activation timing
65+
- asynchronous jobs
66+
- service availability
67+
- preference persistence
68+
- platform-specific behavior
69+
70+
Tests should isolate assumptions as much as possible.
71+
72+
### 6. Keep test setup clear and minimal
73+
Only add the setup required to verify the behavior under test.
74+
Avoid broad fixture initialization when a narrow fixture will do.
75+
76+
### 7. Maintain test readability
77+
Tests should make it clear:
78+
- what is being verified
79+
- under what conditions
80+
- what result is expected
81+
- why a runtime or UI-level test is necessary if one is used
82+
83+
### 8. Handle cleanup properly
84+
Tests should clean up:
85+
- workspace resources they create
86+
- preferences they modify
87+
- listeners or services they register
88+
- open UI artifacts when relevant
89+
- temporary files or runtime state
90+
91+
Avoid leaving hidden shared state between test runs.
92+
93+
## Testing Checklist
94+
95+
Before considering a testing task complete, check:
96+
- chosen test level is appropriate
97+
- tests align with the repository's existing framework and structure
98+
- tests are compatible with minimum Eclipse and JDK versions
99+
- UI tests avoid brittle timing assumptions
100+
- runtime assumptions are explicit and controlled
101+
- created resources and state are cleaned up
102+
- test names and assertions clearly describe behavior
103+
104+
## Output Expectations
105+
106+
When proposing or implementing plugin tests, include relevant notes about:
107+
- why the chosen test level is appropriate
108+
- whether the tests require PDE, Tycho runtime, or SWTBot support
109+
- any extra test bundle, manifest, or build updates that may be required
110+
- any known sources of test fragility and how they were minimized

0 commit comments

Comments
 (0)