Fix @attribute prefix ignored in array elements#52
Merged
Conversation
The @ prefix for XML attributes was only handled at the top level of buildXmlNode but not within array-of-objects processing. Fields like @implementation in plugin configuration arrays were incorrectly created as child elements instead of XML attributes. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
📝 WalkthroughWalkthrough
Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning Review ran into problems🔥 ProblemsGit: Failed to clone repository. Please run the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
extension/src/test/java/eu/maveniverse/maven/mason/YamlParserTest.java (1)
190-242: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd one assertion path for wrapper-object array entries.
This test validates the regular-object array form, but not the wrapper-object form (
- transformer: { "@implementation": ... }), which is also modified inbuildXmlNode. Adding that variant here (or a companion fixture) would lock both branches.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@extension/src/test/java/eu/maveniverse/maven/mason/YamlParserTest.java` around lines 190 - 242, The testBuildPluginConfigAttributes method currently validates the regular-object array form for plugin transformer configuration, but does not test the wrapper-object form (using attributes like "`@implementation`" instead of "implementation") which is also handled in the buildXmlNode method. Add a new test method or companion YAML fixture that covers the wrapper-object array entry variant to ensure both code branches are properly tested and validated.extension/src/main/java/eu/maveniverse/maven/mason/JsonReaderHelper.java (1)
234-259: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winExtract the object-field split into a shared helper.
Both branches now duplicate the same
@-attribute vs child-node parsing. This is exactly the behavior that previously drifted between paths; centralizing it reduces regression risk.♻️ Suggested direction
+private static ParsedXmlObject parseObjectFields( + JsonParser parser, InputSource inputSrc, boolean addLocationInformation) throws IOException { + Map<String, String> attributes = new LinkedHashMap<>(); + List<XmlNode> children = new ArrayList<>(); + JsonToken token = parser.currentToken(); + while (token == JsonToken.FIELD_NAME) { + String field = parser.currentName(); + token = parser.nextToken(); + if (field.startsWith("@")) { + attributes.put(field.substring(1), parser.getText()); + } else { + children.add(XmlNode.newInstance( + field, parser.getText(), new LinkedHashMap<>(), new ArrayList<>(), + createLocation(parser, inputSrc, addLocationInformation))); + } + token = parser.nextToken(); + } + return new ParsedXmlObject(attributes, children); +}Also applies to: 260-283
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@extension/src/main/java/eu/maveniverse/maven/mason/JsonReaderHelper.java` around lines 234 - 259, The object-field parsing logic (checking if objFieldName starts with "@" to classify as attribute versus child node) is duplicated across multiple branches. Extract this conditional logic that differentiates between attributes and child nodes into a shared helper method. This helper should take the field name, parser state, and relevant collections (objAttributes and objectChildren), then handle the attribute-vs-child-node classification consistently. Call this helper method from all locations where the objFieldName.startsWith("@") pattern is currently duplicated to ensure consistent behavior and reduce regression risk across different parsing paths.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@extension/src/main/java/eu/maveniverse/maven/mason/JsonReaderHelper.java`:
- Around line 234-259: The object-field parsing logic (checking if objFieldName
starts with "@" to classify as attribute versus child node) is duplicated across
multiple branches. Extract this conditional logic that differentiates between
attributes and child nodes into a shared helper method. This helper should take
the field name, parser state, and relevant collections (objAttributes and
objectChildren), then handle the attribute-vs-child-node classification
consistently. Call this helper method from all locations where the
objFieldName.startsWith("@") pattern is currently duplicated to ensure
consistent behavior and reduce regression risk across different parsing paths.
In `@extension/src/test/java/eu/maveniverse/maven/mason/YamlParserTest.java`:
- Around line 190-242: The testBuildPluginConfigAttributes method currently
validates the regular-object array form for plugin transformer configuration,
but does not test the wrapper-object form (using attributes like
"`@implementation`" instead of "implementation") which is also handled in the
buildXmlNode method. Add a new test method or companion YAML fixture that covers
the wrapper-object array entry variant to ensure both code branches are properly
tested and validated.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e0ef9c5f-459a-4c31-b67a-2f4562b6bcd7
📒 Files selected for processing (3)
extension/src/main/java/eu/maveniverse/maven/mason/JsonReaderHelper.javaextension/src/test/java/eu/maveniverse/maven/mason/YamlParserTest.javaextension/src/test/resources/yaml/build-plugin-config-attributes.yaml
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Claude Code on behalf of Guillaume Nodet
Summary
@prefix for XML attributes being ignored when processing objects inside arrays inbuildXmlNodeJsonReaderHelper(wrapper objects and regular objects within arrays) created child elements for all fields without checking for the@prefix — only the top-level code path handled it correctlytransformersuse case from the issueExample
This YAML configuration now correctly produces
<transformer implementation="...">instead of<transformer><@implementation>...</@implementation></transformer>:Test plan
testBuildPluginConfigAttributesverifies shade plugin transformer configuration with@implementationattributesFixes #28
Summary by CodeRabbit
New Features
Tests