Validate SkyWalking OAP changes by building the backend or full project and running Javadoc and Checkstyle checks. Choose commands for a full CI-style build, a faster backend build, one check, or a single module before submitting a pull request.
Build SkyWalking OAP server, run javadoc checks, and verify checkstyle. Use to validate changes before submitting a PR.
Run score Not tested
See how to installThis skill guides you through building SkyWalking OAP changes with the Maven wrapper. Choose a full build, a backend-only build, Javadoc checks, Checkstyle checks, or a build for a single module. For Javadoc, it explains how to distinguish errors that fail the build from warnings, and how to fix common documentation mistakes.
Use it before submitting a pull request to check that changes compile and pass documentation generation and code-style checks. It can also help you build only the module you changed.
You need JDK 11, 17, or 21 and Maven 3.6 or later. Use the ./mvnw wrapper. Even for a standalone Javadoc check, run install first.
This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.
AI checked the SKILL.md for operations that need care and for setup requirements. The score comes only from actually running the skill (hands-on test).
Not counted in the score. Rated by AI (OpenAI Codex) as of Oct 29, 2026. Treat it as a guide and read the original before installing.
Review the instructions the agent will receive before you install.
Build the project and run static checks matching CI.
./mvnw wrapper)backend (default): Builds OAP server modulesui (default): Builds web applicationdist (default): Creates distribution packagesall: Builds everything including submodule initializationall or no argument — full CI build./mvnw clean flatten:flatten install javadoc:javadoc -B -q -Pall \
-Dmaven.test.skip \
-Dcheckstyle.skip \
-Dgpg.skip
backend — backend only (faster)./mvnw clean flatten:flatten package -Pbackend,dist -Dmaven.test.skip
javadoc — javadoc check onlyJavadoc requires delombok output, so install must run first:
./mvnw clean flatten:flatten install javadoc:javadoc -B -q -Pall \
-Dmaven.test.skip \
-Dcheckstyle.skip \
-Dgpg.skip
Running javadoc:javadoc alone without install will miss errors because ${delombok.output.dir} won't be populated.
checkstyle — checkstyle only./mvnw -B -q clean flatten:flatten checkstyle:check
./mvnw clean flatten:flatten package -pl oap-server/analyzer/<module-name> -Dmaven.test.skip
Maven prefixes all javadoc output with [ERROR], but the actual severity is in the message after the line number. Only lines containing error: fail the build; lines with warning: do not.
[ERROR] Foo.java:42: error: bad use of '>' ← ACTUAL ERROR (must fix)
[ERROR] Foo.java:50: warning: no @param for <T> ← WARNING (does not fail build)
| Error | Cause | Fix |
|---|---|---|
bad use of '>' | Bare > in javadoc HTML (e.g., -> in <pre> blocks) | Use {@code ->} or -> |
| heading out of sequence | Heading level skips the expected hierarchy | See heading rules below |
| reference not found | {@link Foo#bar()} with wrong signature | Match exact parameter types: {@link Foo#bar(ArgType)} |
Strict heading validation was introduced in JDK 13. JDK 11 does not enforce it, but JDK 17/21/25 do. Write headings correctly for forward compatibility:
| Javadoc location | Start heading at |
|---|---|
| Class, interface, enum, package, module | <h2> |
| Constructor, method, field | <h4> |
Standalone HTML files (doc-files/) | <h1> |
The generated javadoc page uses <h1> for the class name and <h3> for member sections (Methods, Fields, etc.), so class-level subsections must use <h2> and method-level subsections must use <h4> to maintain proper nesting.
CI uses JDK 11 on Linux. The dist-tar job runs:
./mvnw clean flatten:flatten install javadoc:javadoc -B -q -Pall \
-Dmaven.test.skip \
-Dcheckstyle.skip \
-Dgpg.skip
The code-style job runs:
./mvnw -B -q clean flatten:flatten checkstyle:check
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use this skill to investigate failed end-to-end tests in GitHub Actions. It downloads the run’s log artifacts, checks OAP and other component logs for errors, and summarizes the likely root cause, including failures in standalone test tools.
Compile SkyWalking DSL scripts for MAL, OAL, LAL, or Hierarchy and save the generated .class files for inspection. Choose one DSL or generate classes for all four, then locate the output and use javap to examine bytecode.
Prepare a pull request branch by running the documented build, style, license-header, and Java import checks, then committing and pushing the changes. If the branch has no pull request yet, create one using the project template.
Check whether source files carry the required Apache 2.0 headers and whether the dependency license file matches current dependencies. Use the provided commands to fix headers or regenerate the license list, then review any changes before submitting a pull request.
Plan how to add a monitoring target or layer to SkyWalking OAP. The guide maps signals such as metrics, logs, and spans to extension points, and identifies related layer registration, UI templates, documentation, and local verification work.
Rebuild SkyWalking’s distribution and OAP Docker image after source changes, choosing a command sequence that includes the updated JARs. It also explains how to inspect the image contents before running end-to-end tests.