zhongwei/gh-motlin-claude-code-plugins-plugins-java
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:41:08 +08:00
commit f782c8ace0
8 changed files with 508 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,19 @@
{
"name": "java",
"description": "Java and Maven tools for OpenRewrite import ordering and POM dependency management",
"version": "0.18.0",
"author": {
"name": "Craig Motlin"
},
"skills": [
"./skills/openrewrite/SKILL.md",
"./skills/pom-ordering/SKILL.md"
],
"agents": [
"./agents/liquibase-lock-resolver.md"
],
"commands": [
"./commands/openrewrite-imports.md",
"./commands/pom-ordering.md"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# java
Java and Maven tools for OpenRewrite import ordering and POM dependency management

39
agents/liquibase-lock-resolver.md Normal file
View File

@@ -0,0 +1,39 @@
---
name: liquibase-lock-resolver
description: Use this agent when you encounter a Liquibase lock error during Maven builds, specifically when you see error messages indicating 'Could not acquire change log lock' or 'Currently locked by' in test failures. Examples:\n\n<example>\nContext: During development, a Maven build fails with Liquibase lock errors.\nuser: "Run the tests"\nassistant: "I'll run the tests for you"\n<maven test output shows Liquibase lock errors>\nassistant: "I see there's a Liquibase lock error. Let me use the liquibase-lock-resolver agent to clean up the test databases"\n<commentary>\nThe build failed due to Liquibase locks, so the liquibase-lock-resolver agent should be used to clean up H2 test databases.\n</commentary>\n</example>\n\n<example>\nContext: User reports test failures related to database locks.\nuser: "The tests are failing with 'Could not acquire change log lock' errors"\nassistant: "I'll use the liquibase-lock-resolver agent to clean up the locked test databases"\n<commentary>\nThe user explicitly mentioned Liquibase lock errors, triggering the need for the liquibase-lock-resolver agent.\n</commentary>\n</example>
tools: Task, Bash, Glob, Grep, LS, ExitPlanMode, Read, Edit, MultiEdit, Write, NotebookRead, NotebookEdit, WebFetch, TodoWrite, WebSearch
color: gold
---
🔓 Resolve Liquibase database lock errors.
You are a specialized database lock resolution expert focused on fixing Liquibase lock errors in Maven-based Java projects. Your primary responsibility is to identify and remove H2 test databases that have become locked, preventing tests from running successfully.
When activated, you will:
1. **Diagnose the Lock Issue**: Confirm that the error is indeed a Liquibase lock error by examining the error output for patterns like:
- 'Could not acquire change log lock'
- 'Currently locked by'
- 'liquibase.exception.LockException'
2. **Locate Test Databases**: Search for H2 database files in all `target/` directories throughout the project. These typically have extensions like:
- `.db`
- `.mv.db`
- `.trace.db`
- `.lock.db`
3. **Clean Up Databases**: Delete all H2 test database files found in `target/` directories. You should:
- Use recursive search to find all `target/` directories
- Remove only H2 database files, not other build artifacts
- Provide clear feedback about which files were deleted
4. **Verify Resolution**: After cleanup, re-run the tests to confirm the lock issue is resolved.
You should be careful to:
- Only delete files in `target/` directories (never in `src/` or other source directories)
- Only target H2 database files, not other types of files
- Provide a summary of actions taken
- If no H2 database files are found, suggest alternative solutions
Your approach should be systematic and safe, ensuring you don't accidentally delete important files while resolving the lock issue. Always explain what you're doing and why, so the user understands the resolution process.

140
commands/openrewrite-imports.md Normal file
View File

@@ -0,0 +1,140 @@
---
description: Fix OpenRewrite import ordering test failures
---
🔧 Fixing OpenRewrite Import Ordering Test Failures
## Problem
OpenRewrite recipe tests fail with diffs showing only import order differences, not actual transformation issues.
## Symptoms
- Test failure shows the transformation worked correctly
- Only difference is the order of import statements
- Error looks like:
```diff
-import java.util.List;
-import org.assertj.core.api.Assertions;
+import org.assertj.core.api.Assertions;
+import java.util.List;
```
## Root Cause
OpenRewrite manages imports automatically based on:
- Existing imports in the file
- JavaTemplate configuration
- Import optimization rules
- The order may differ from your test expectations
## Solution Approach
### 1. Fix the Recipe (if imports are missing)
Ensure your JavaTemplate is properly configured:
```java
JavaTemplate template = JavaTemplate
.builder("Your.template.code()")
.imports(
"org.assertj.core.api.Assertions",
"org.eclipse.collections.impl.utility.Iterate"
)
.contextSensitive() // Important for proper context handling
.javaParser(JavaParser.fromJavaVersion()
.classpath("assertj-core", "eclipse-collections", "eclipse-collections-api")
)
.build();
```
Don't forget to call:
```java
maybeAddImport("org.assertj.core.api.Assertions");
maybeAddImport("org.eclipse.collections.impl.utility.Iterate");
maybeRemoveImport("old.package.OldClass");
```
### 2. Fix the Test Expectations
Accept the actual import order that OpenRewrite produces:
**Instead of forcing a specific order:**
```java
// DON'T expect a specific order you want
"import java.util.List;\n" +
"import org.assertj.core.api.Assertions;\n"
```
**Use the actual order OpenRewrite produces:**
```java
// DO accept the order OpenRewrite generates
"import org.assertj.core.api.Assertions;\n" +
"import org.eclipse.collections.impl.utility.Iterate;\n" +
"\n" +
"import java.util.List;\n"
```
### 3. Common Import Ordering Patterns
OpenRewrite typically orders imports as:
1. Third-party packages (org.assertj, org.eclipse.collections, etc.)
2. Blank line
3. Java standard library (`java.*`, `javax.*`)
4. Blank line (if static imports exist)
5. Static imports
## Quick Fix Steps
1. Run the failing test and copy the actual output from the error message
2. Replace the expected output in your test with the actual output
3. Verify the transformation logic is correct (ignore import order)
4. Re-run the test to confirm it passes
## Note on ~~> Syntax
The `~~>` prefix in test expectations is not standard in this codebase. It's used in some OpenRewrite projects to indicate "ignore everything before this line" but isn't recognized in all contexts. If you see it failing, remove it and use exact matching instead.
## Example Fix
```java
@Test
void replacesVerifyWithAssertJ() {
rewriteRun(
java(
// Input
"""
import org.eclipse.collections.impl.test.Verify;
import java.util.List;
class Test {
void test() {
List<String> list = List.of("a", "b", "c");
Verify.assertCount(2, list, each -> each.length() > 0);
}
}
""",
// Expected output - use actual order from test failure
"""
import org.assertj.core.api.Assertions;
import org.eclipse.collections.impl.utility.Iterate;
import java.util.List;
class Test {
void test() {
List<String> list = List.of("a", "b", "c");
Assertions.assertThat(Iterate.count(list, each -> each.length() > 0)).isEqualTo(2);
}
}
"""
)
);
}
```

5
commands/pom-ordering.md Normal file
View File

@@ -0,0 +1,5 @@
---
description: Check Maven POM file dependency ordering
---
Use the pom-ordering skill to check edited maven pom.xml files in the project. If none have local modifications, check them all.

61
plugin.lock.json Normal file
View File

@@ -0,0 +1,61 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:motlin/claude-code-plugins:plugins/java",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "e83082ac06549b4dbd5a03cd7360ab40f9647198",
"treeHash": "7bd589f37e2906610c466297091f5529afc130b3d5b06492e2eeea5b60d7fa66",
"generatedAt": "2025-11-28T10:27:10.306341Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "java",
"description": "Java and Maven tools for OpenRewrite import ordering and POM dependency management",
"version": "0.18.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "73b5da92ddbd4555ba406631976a4d9b20df8cd8aa64f895305fb24460658bf8"
},
{
"path": "agents/liquibase-lock-resolver.md",
"sha256": "0db982b32984f9a7a13933e83fbcb97c1e5e858a150d35db2bbfb2efa284a329"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "f0eef550ab39931c87be3c76790cbeb97655d84fa6f751779906ad9dbf164254"
},
{
"path": "commands/pom-ordering.md",
"sha256": "4b84330d90191a7df6cc6922dcc8aa54643c9e410cd2ab33e42da065119e8f49"
},
{
"path": "commands/openrewrite-imports.md",
"sha256": "a6550ebddc0be532b904b48cc7b5189bc79b8c5c35ff9a948660cd6441b81ac5"
},
{
"path": "skills/openrewrite/SKILL.md",
"sha256": "33f0d45d2052930c3e38528d8bc9ee5a59aa85e2a5e62f7df7216562e495cbe3"
},
{
"path": "skills/pom-ordering/SKILL.md",
"sha256": "a223b237c6ccd049351aafd44273beeacc0ffa228b0b70c829b02de3589c63e5"
}
],
"dirSha256": "7bd589f37e2906610c466297091f5529afc130b3d5b06492e2eeea5b60d7fa66"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

145
skills/openrewrite/SKILL.md Normal file
View File

@@ -0,0 +1,145 @@
---
name: openrewrite
description: OpenRewrite recipe development and test maintenance. Use when writing OpenRewrite recipes, fixing test failures, or working with import ordering in recipe tests.
---
# OpenRewrite Recipe Development
This skill provides guidelines for developing OpenRewrite recipes and maintaining their tests, with a focus on import ordering issues.
## Fixing Import Ordering Test Failures
🔧 OpenRewrite recipe tests often fail due to import order differences, not actual transformation issues.
### Problem
OpenRewrite recipe tests fail with diffs showing only import order differences:
```diff
-import java.util.List;
-import org.assertj.core.api.Assertions;
+import org.assertj.core.api.Assertions;
+import java.util.List;
```
### Root Cause
OpenRewrite manages imports automatically based on:
- Existing imports in the file
- JavaTemplate configuration
- Import optimization rules
- The order may differ from test expectations
### Solution Approach
#### 1. Fix the Recipe (if imports are missing)
Ensure your JavaTemplate is properly configured:
```java
JavaTemplate template = JavaTemplate
.builder("Your.template.code()")
.imports(
"org.assertj.core.api.Assertions",
"org.eclipse.collections.impl.utility.Iterate"
)
.contextSensitive() // Important for proper context handling
.javaParser(JavaParser.fromJavaVersion()
.classpath("assertj-core", "eclipse-collections", "eclipse-collections-api")
)
.build();
```
Don't forget to call:
```java
maybeAddImport("org.assertj.core.api.Assertions");
maybeAddImport("org.eclipse.collections.impl.utility.Iterate");
maybeRemoveImport("old.package.OldClass");
```
#### 2. Fix the Test Expectations
Accept the actual import order that OpenRewrite produces:
❌ Instead of forcing a specific order:
```java
// DON'T expect a specific order you want
"import java.util.List;\n" +
"import org.assertj.core.api.Assertions;\n"
```
✅ Use the actual order OpenRewrite produces:
```java
// DO accept the order OpenRewrite generates
"import org.assertj.core.api.Assertions;\n" +
"import org.eclipse.collections.impl.utility.Iterate;\n" +
"\n" +
"import java.util.List;\n"
```
#### 3. Common Import Ordering Patterns
OpenRewrite typically orders imports as:
1. Third-party packages (org.assertj, org.eclipse.collections, etc.)
2. Blank line
3. Java standard library (`java.*`, `javax.*`)
4. Blank line (if static imports exist)
5. Static imports
### Quick Fix Steps
1. Run the failing test and copy the actual output from the error message
2. Replace the expected output in your test with the actual output
3. Verify the transformation logic is correct (ignore import order)
4. Re-run the test to confirm it passes
### Note on ~~> Syntax
The `~~>` prefix in test expectations is not standard in all codebases. It's used in some OpenRewrite projects to indicate "ignore everything before this line" but isn't recognized in all contexts. If you see it failing, remove it and use exact matching instead.
### Example Fix
```java
@Test
void replacesVerifyWithAssertJ() {
rewriteRun(
java(
// Input
"""
import org.eclipse.collections.impl.test.Verify;
import java.util.List;
class Test {
void test() {
List<String> list = List.of("a", "b", "c");
Verify.assertCount(2, list, each -> each.length() > 0);
}
}
""",
// Expected output - use actual order from test failure
"""
import org.assertj.core.api.Assertions;
import org.eclipse.collections.impl.utility.Iterate;
import java.util.List;
class Test {
void test() {
List<String> list = List.of("a", "b", "c");
Assertions.assertThat(Iterate.count(list, each -> each.length() > 0)).isEqualTo(2);
}
}
"""
)
);
}
```
## Maven POM Dependency Ordering
Maven POM files should follow a consistent dependency ordering structure. See the `pom-ordering` skill for detailed guidelines.

96
skills/pom-ordering/SKILL.md Normal file
View File

@@ -0,0 +1,96 @@
---
name: pom-ordering
description: Enforce Maven POM dependency ordering rules. This skill should be used when editing pom.xml files.
---
## Ordering Rules
First, group dependencies by scope (compile, runtime, test).
Within each scope, group by groupId in this order:
1. First-party (${project.groupId} or modules within the project)
2. cool.klass
3. io.liftwizard
4. org.eclipse.collections
5. io.dropwizard
6. Other third-party libraries
7. Jakarta
## Region Comment Structure
Use region comments for each groupId+scope combination:
- `<!--region Project compile dependencies -->`
- `<!--region Project runtime dependencies -->`
- `<!--region Klass compile dependencies -->`
- `<!--region Klass runtime dependencies -->`
- `<!--region Liftwizard compile dependencies -->`
- `<!--region Liftwizard runtime dependencies -->`
- `<!--region Compile dependencies -->` (for other dependencies)
- `<!--region Runtime dependencies -->`
- `<!--region Test dependencies -->`
Close each region with `<!--endregion [name] -->`
Within some groups, use nested regions for further organization:
- For io.liftwizard runtime: `<!--region Liftwizard bundles -->` then `<!--region Liftwizard config-->`
- For io.dropwizard: core modules first, then specialized modules
## Example Structure
```xml
<dependencies>
<!--region Project compile dependencies -->
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>example-services</artifactId>
<version>${project.version}</version>
</dependency>
<!--endregion-->
<!--region Project runtime dependencies -->
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>example-domain-model</artifactId>
<version>${project.version}</version>
<scope>runtime</scope>
</dependency>
<!--endregion-->
<!--region Liftwizard runtime dependencies -->
<dependency>
<groupId>io.liftwizard</groupId>
<artifactId>liftwizard-graphql-reladomo-meta</artifactId>
<scope>runtime</scope>
</dependency>
<!--region Liftwizard bundles -->
<dependency>
<groupId>io.liftwizard</groupId>
<artifactId>liftwizard-bundle-cors</artifactId>
<scope>runtime</scope>
</dependency>
<!--endregion-->
<!--region Liftwizard config-->
<dependency>
<groupId>io.liftwizard</groupId>
<artifactId>liftwizard-config-logging-logstash-console</artifactId>
<scope>runtime</scope>
</dependency>
<!--endregion-->
<!--endregion-->
<!--region Test dependencies -->
<dependency>
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter</artifactId>
<scope>test</scope>
</dependency>
<!--endregion-->
</dependencies>
```