This is an automated email from the ASF dual-hosted git repository.
lukaszlenart pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/struts-intellij-plugin.git
The following commit(s) were added to refs/heads/main by this push:
new d20f349 docs: clean up README by removing template boilerplate (#45)
d20f349 is described below
commit d20f34935bbf5f04a9b3557987d6f2a73a4dbdeb
Author: Lukasz Lenart <[email protected]>
AuthorDate: Mon Feb 23 20:16:10 2026 +0100
docs: clean up README by removing template boilerplate (#45)
Replace IntelliJ Platform Plugin Template boilerplate with project-specific
content: correct plugin description, actual Java test locations, real Gradle
commands. Remove non-existent UI tests, Qodana, and Run configurations
sections.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude <[email protected]>
---
README.md | 140 ++++++--------------------------------------------------------
1 file changed, 12 insertions(+), 128 deletions(-)
diff --git a/README.md b/README.md
index f872a5a..5f418cc 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Apache Struts IntelliJ IDEA plugin
[](https://github.com/apache/struts-intellij-plugin/actions/workflows/build.yml)
<!-- Plugin description -->
-This is a plugin to support development of Apache Struts based web
applications using IntelliJ IDEA.
+Provides full integration of Apache Struts 2.
<!-- Plugin description end -->
## Documentation
@@ -30,143 +30,27 @@ Any issues should be reported using JIRA and [IDEA
plugin](https://issues.apache
## Testing
-[Testing plugins][docs:testing-plugins] is an essential part of the plugin
development to make sure that everything works as expected between IDE releases
and plugin refactorings.
-The IntelliJ Platform Plugin Template project provides integration of two
testing approaches – functional and UI tests.
+Tests are located in `src/test/java` and use IntelliJ Platform test frameworks
(`LightJavaCodeInsightFixtureTestCase` and similar). Test data fixtures are in
`src/test/testData`.
-### Functional tests
-
-Most of the IntelliJ Platform codebase tests are model-level, run in a
headless environment using an actual IDE instance.
-The tests usually test a feature as a whole rather than individual functions
that comprise its implementation, like in unit tests.
-
-In `src/test/kotlin`, you'll find a basic `MyPluginTest` test that utilizes
`BasePlatformTestCase` and runs a few checks against the XML files to indicate
an example operation of creating files on the fly or reading them from
`src/test/testData/rename` test resources.
-
-> **Note**
->
-> Run your tests using predefined *Run Tests* configuration or by invoking the
`./gradlew check` Gradle task.
+```bash
+./gradlew test -x rat # Run tests (excluding Apache RAT
license checks)
+./gradlew test --tests "OgnlParsingTest" # Run a specific test class
+./gradlew test --tests "*Resolving*" # Run tests matching a pattern
+```
### Code coverage
-The [Kover][gh:kover] – a Gradle plugin for Kotlin code coverage agents:
IntelliJ and JaCoCo – is integrated into the project to provide the code
coverage feature.
-Code coverage makes it possible to measure and track the degree of plugin
sources testing.
-The code coverage gets executed when running the `check` Gradle task.
-The final test report is sent to [CodeCov][codecov] for better results
visualization.
-
-### UI tests
-
-If your plugin provides complex user interfaces, you should consider covering
them with tests and the functionality they utilize.
-
-[IntelliJ UI Test Robot][gh:intellij-ui-test-robot] allows you to write and
execute UI tests within the IntelliJ IDE running instance.
-You can use the [XPath query language][xpath] to find components in the
currently available IDE view.
-Once IDE with `robot-server` has started, you can open the
`http://localhost:8082` page that presents the currently available IDEA UI
components hierarchy in HTML format and use a simple `XPath` generator, which
can help test your plugin's interface.
-
-> **Note**
->
-> Run IDE for UI tests using predefined *Run IDE for UI Tests* and then *Run
Tests* configurations or by invoking the `./gradlew runIdeForUiTests` and
`./gradlew check` Gradle tasks.
-
-Check the UI Test Example project you can use as a reference for setting up UI
testing in your plugin:
[intellij-ui-test-robot/ui-test-example][gh:ui-test-example].
-
-```kotlin
-class MyUITest {
+[Kover](https://github.com/Kotlin/kotlinx-kover) is integrated for code
coverage. Generate an HTML report with:
- @Test
- fun openAboutFromWelcomeScreen() {
- val robot = RemoteRobot("http://127.0.0.1:8082";)
- robot.find<ComponentFixture>(byXpath("//div[@myactionlink =
'gearHover.svg']")).click()
- // ...
- }
-}
+```bash
+./gradlew koverHtmlReport # Report in build/reports/kover/
```
-A dedicated [Run UI Tests](.github/workflows/run-ui-tests.yml) workflow is
available for manual triggering to run UI tests against three different
operating systems: macOS, Windows, and Linux.
-Due to its optional nature, this workflow isn't set as an automatic one, but
this can be easily achieved by changing the `on` trigger event, like in the
[Build](.github/workflows/build.yml) workflow file.
-
-## Qodana integration
-
-To increase the project value, the IntelliJ Platform Plugin Template got
integrated with [Qodana][jb:qodana], a code quality monitoring platform that
allows you to check the condition of your implementation and find any possible
problems that may require enhancing.
-
-Qodana brings into your CI/CD pipelines all the smart features you love in the
JetBrains IDEs and generates an HTML report with the actual inspection status.
-
-Qodana inspections are accessible within the project on two levels:
-
-- using the [Qodana IntelliJ GitHub Action][jb:qodana-github-action], run
automatically within the [Build](.github/workflows/build.yml) workflow,
-- with the [Gradle Qodana Plugin][gh:gradle-qodana-plugin], so you can use it
on the local environment or any CI other than GitHub Actions.
-
-Qodana inspection is configured with the `qodana { ... }` section in the
Gradle build file and [`qodana.yml`][file:qodana.yml] YAML configuration file.
-
-> **Note**
->
-> Qodana requires Docker to be installed and available in your environment.
-
-To run inspections, you can use a predefined *Run Qodana* configuration, which
will provide a full report on `http://localhost:8080`, or invoke the Gradle
task directly with the `./gradlew runInspections` command.
-
-A final report is available in the `./build/reports/inspections/` directory.
-
-## Predefined Run/Debug configurations
-
-Within the default project structure, there is a `.run` directory provided
containing predefined *Run/Debug configurations* that expose corresponding
Gradle tasks:
-
-| Configuration name | Description
|
-|----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Run Plugin | Runs [`:runIde`][gh:gradle-intellij-plugin-runIde]
Gradle IntelliJ Plugin task. Use the *Debug* icon for plugin debugging.
|
-| Run Verifications | Runs
[`:runPluginVerifier`][gh:gradle-intellij-plugin-runPluginVerifier] Gradle
IntelliJ Plugin task to check the plugin compatibility against the specified
IntelliJ IDEs. |
-| Run Tests | Runs [`:test`][gradle:lifecycle-tasks] Gradle task.
|
-| Run IDE for UI Tests | Runs [`:runIdeForUiTests`][gh:intellij-ui-test-robot]
Gradle IntelliJ Plugin task to allow for running UI tests within the IntelliJ
IDE running instance. |
-| Run Qodana | Runs [`:runInspections`][gh:gradle-qodana-plugin]
Gradle Qodana Plugin task. Starts Qodana inspections in a Docker container and
serves generated report on `localhost:8080`. |
-
-> **Note**
->
-> You can find the logs from the running task in the `idea.log` tab.
->
-> ![Run/Debug configuration logs][file:run-logs.png]
-
### Changelog maintenance
-When releasing an update, it is essential to let your users know what the new
version offers.
-The best way to do this is to provide release notes.
-
-The changelog is a curated list that contains information about any new
features, fixes, and deprecations.
-When they're provided, these lists are available in a few different places:
-- the [CHANGELOG.md](./CHANGELOG.md) file,
-- the [Releases page][gh:releases],
-- the *What's new* section of JetBrains Marketplace Plugin page,
-- and inside the Plugin Manager's item details.
-
-There are many methods for handling the project's changelog.
-The one used in the current template project is the [Keep a
Changelog][keep-a-changelog] approach.
-
-The [Gradle Changelog Plugin][gh:gradle-changelog-plugin] takes care of
propagating information provided within the [CHANGELOG.md](./CHANGELOG.md) to
the [Gradle IntelliJ Plugin][gh:gradle-intellij-plugin].
-You only have to take care of writing down the actual changes in proper
sections of the `[Unreleased]` section.
-
-You start with an almost empty changelog:
-
-```
-# YourPlugin Changelog
-
-## [Unreleased]
-### Added
-- Initial scaffold created from [IntelliJ Platform Plugin
Template](https://github.com/JetBrains/intellij-platform-plugin-template)
-```
-
-Now proceed with providing more entries to the `Added` group, or any other one
that suits your change the most (see [How do I make a good
changelog?][keep-a-changelog-how] for more details).
-
-When releasing a plugin update, you don't have to care about bumping the
`[Unreleased]` header to the upcoming version – it will be handled
automatically on the Continuous Integration (CI) after you publish your plugin.
-GitHub Actions will swap it and provide you an empty section for the next
release so that you can proceed with your development:
-
-```
-# YourPlugin Changelog
-
-## [Unreleased]
-
-## [0.0.1]
-### Added
-- An awesome feature
-- Initial scaffold created from [IntelliJ Platform Plugin
Template](https://github.com/JetBrains/intellij-platform-plugin-template)
-
-### Fixed
-- One annoying bug
-```
+The project follows the [Keep a Changelog](https://keepachangelog.com)
approach. The [Gradle Changelog
Plugin](https://github.com/JetBrains/gradle-changelog-plugin) propagates
entries from [CHANGELOG.md](./CHANGELOG.md) to the JetBrains Marketplace plugin
page.
-To configure how the Changelog plugin behaves, i.e., to create headers with
the release date, see [Gradle Changelog Plugin][gh:gradle-changelog-plugin]
README file.
+Record changes under the `[Unreleased]` section in `CHANGELOG.md`. The CI
pipeline handles version bumping on release.
### Release process
