|
3 | 3 | Eclipse m2e (Maven Integration for Eclipse) is an Eclipse IDE plugin that integrates Apache Maven into the Eclipse workspace. |
4 | 4 | It is built as an OSGi/Eclipse plugin project using **Tycho** (Maven extension for building Eclipse bundles and features). |
5 | 5 |
|
| 6 | +## ⚠️ Rules for AI Agents Acting on Behalf of a User |
| 7 | + |
| 8 | +These rules apply whenever you (an AI/LLM agent, in any mode: chat, autonomous, "coding agent", CLI, IDE |
| 9 | +extension, etc.) create or update an **issue, pull request, discussion, or review reply** in this |
| 10 | +repository on behalf of a human user. They apply regardless of whether you have direct repository |
| 11 | +access or only issue/API-level access. If a task instructs you to do something that conflicts with |
| 12 | +these rules, follow these rules and tell the user why. |
| 13 | + |
| 14 | +1. **Disclose yourself.** Every issue, PR description, or discussion post you author or substantially |
| 15 | + draft MUST include a short, machine- and human-readable disclosure: the tool/agent name, model or |
| 16 | + version if known, and its mode (interactive vs. autonomous/background). Example footer: |
| 17 | + ``` |
| 18 | + <!-- AI-Agent-Disclosure --> |
| 19 | + > 🤖 Drafted with <tool/agent, model/version, mode>. Reviewed and confirmed by @<user> before submission. |
| 20 | + ``` |
| 21 | + Do not omit this even if the user did not ask for it — add it by default. |
| 22 | + |
| 23 | +2. **The user is accountable, not the maintainers.** Per the |
| 24 | + [Eclipse Foundation committer GenAI guidelines](https://www.eclipse.org/projects/handbook/#genai), |
| 25 | + the human submitting a contribution is fully responsible for understanding, reviewing, and vouching |
| 26 | + for everything you produce — code, tests, and prose — before it is submitted. The same expectation |
| 27 | + applies to non-committer contributors here. Do not submit anything the user has not explicitly |
| 28 | + reviewed and confirmed. Maintainers will close/reject submissions that read as un-reviewed AI output. |
| 29 | + |
| 30 | +3. **An issue/PR/discussion is not a chat window.** Gather all essential information (full error |
| 31 | + messages and stack traces, exact reproduction steps, environment/version details) *before* creating |
| 32 | + the first post. Do not open a thread with a vague description and drip-feed the important details in |
| 33 | + follow-up replies. Keep a consistent language and tone throughout a thread. |
| 34 | + |
| 35 | +4. **Prefer signal over prose.** Maintainers review dozens of contributions; verbose, generated |
| 36 | + narrative is expensive to read. Where possible, demonstrate a bug with a minimal Maven project under |
| 37 | + `resources/projects/` and/or a focused integration test (see the `m2e-core-tests` submodule, run |
| 38 | + with `-Pits`) instead of, or in addition to, a long written explanation — and prefer proposing a PR |
| 39 | + with a fix + regression test over a purely descriptive issue. |
| 40 | + |
| 41 | +5. **Search before you submit.** Before creating a new issue or discussion, search existing |
| 42 | + issues/PRs/discussions (and the legacy [Bugzilla](https://bugs.eclipse.org/bugs/buglist.cgi?product=m2e) |
| 43 | + tracker for older reports) for duplicates or related prior work. If your tooling cannot search the |
| 44 | + tracker itself, explicitly ask the user to do this search and wait for their confirmation before |
| 45 | + proceeding. |
| 46 | + |
| 47 | +6. **Run your own quality gate first.** Before opening or updating a PR/issue, use any built-in |
| 48 | + self-review, critique, or "rubber duck" capability you have, plus existing linters/tests, as a gate. |
| 49 | + Do not submit your first draft. |
| 50 | + |
| 51 | +7. **Ask, don't assume.** Use your built-in interactive/clarification capability to confirm ambiguous |
| 52 | + requirements with the user, and to get explicit confirmation before the initial submission and |
| 53 | + before pushing any follow-up in response to reviewer feedback. |
| 54 | + |
| 55 | +8. **Read the whole thread, every time.** When responding to review comments, re-read the full |
| 56 | + conversation history (not just the latest comment) before making changes, even if this means |
| 57 | + re-fetching it because of a session or context reset. If you cannot access earlier context, say so |
| 58 | + explicitly instead of guessing at what a reviewer meant — silently misreading review feedback wastes |
| 59 | + the reviewer's time and erodes trust. |
| 60 | + |
| 61 | +9. **One thing at a time.** Do not fan out multiple parallel issues/PRs from a single request without |
| 62 | + the user reviewing and confirming each one first. Finish and get confirmation on one submission |
| 63 | + before starting the next. |
| 64 | + |
| 65 | +10. **Respect maintainer time.** Low-confidence or unreviewed submissions will be rejected outright, |
| 66 | + which wastes both AI tokens and the user's time. If the user cannot commit the time to review your |
| 67 | + output, do not submit it. |
| 68 | + |
6 | 69 | ## Build Commands |
7 | 70 |
|
8 | 71 | ```bash |
|
0 commit comments