Issue 11201

[anatol-sialitski]

No description provided.

[codecov]

Codecov Report

Attention: Patch coverage is 85.71429% with 1 line in your changes missing coverage. Please review.

Project coverage is 86.04%. Comparing base (c8b7ac5) to head (e15a1ba).

Files with missing lines	Patch %	Lines
.../com/enonic/xp/lib/schema/JsonSchemaValidator.java	85.71%	1 Missing ⚠️

Additional details and impacted files

@@                    Coverage Diff                     @@
##             persisted-schema-poc   #11202      +/-   ##
==========================================================
- Coverage                   86.04%   86.04%   -0.01%     
- Complexity                  19710    19713       +3     
==========================================================
  Files                        2573     2574       +1     
  Lines                       67925    67932       +7     
  Branches                     5432     5432              
==========================================================
+ Hits                        58443    58449       +6     
- Misses                       6887     6888       +1     
  Partials                     2595     2595              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[codacy-production]

ℹ️ Codacy found a minor CodeStyle issue: Redundant 'final' modifier.

The issue identified by the Checkstyle linter indicates that the final modifier is considered redundant in the method parameter declaration. In Java, method parameters are implicitly final, meaning they cannot be reassigned within the method body. Therefore, explicitly declaring them as final is unnecessary and can lead to code that is less clean and more difficult to read.

To fix the issue, we can simply remove the final keyword from the method parameter in the registerInputTypeSchema method.

Here’s the code suggestion for the change:

Suggested change

	String registerInputTypeSchema( final String jsonSchemaDefinition );
	String registerInputTypeSchema(String jsonSchemaDefinition);

---

This comment was generated by an experimental AI tool.

[codacy-production]

ℹ️ Codacy found a minor CodeStyle issue: Redundant 'final' modifier.

The issue reported by the Checkstyle linter indicates that the final modifier is considered redundant for the parameter contentTypeAsYml in the method isContentTypeValid. In Java, method parameters are implicitly final unless explicitly marked otherwise, meaning they cannot be reassigned within the method body. Thus, adding the final modifier is unnecessary and can be removed to comply with the coding standards.

Here's the suggested code change:

Suggested change

	boolean isContentTypeValid( final String contentTypeAsYml );
	boolean isContentTypeValid( String contentTypeAsYml );

---

This comment was generated by an experimental AI tool.

[codacy-production]

ℹ️ Codacy found a minor CodeStyle issue: Redundant 'final' modifier.

The issue reported by the Checkstyle linter indicates that the final modifier is unnecessary for the parameter yml in the method declaration boolean isSchemaValid( final String schemaId, final String yml );. In Java, method parameters are implicitly final unless explicitly stated otherwise, meaning that they cannot be reassigned within the method. Therefore, including the final keyword for method parameters is redundant and can be removed to conform to the coding standards.

To fix the issue, we can simply remove the final modifier from the yml parameter. Here is the suggested code change:

Suggested change

	boolean isSchemaValid( final String schemaId, final String yml );
	boolean isSchemaValid( final String schemaId, String yml );

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium UnusedCode issue: Unused import - com.enonic.xp.inputtype.InputTypeProperty.

The issue reported by the Checkstyle linter indicates that the import statement for InputTypeProperty is not being used anywhere in the YmlFormParser class. Unused imports can clutter the code and should be removed to maintain clean and readable code.

To fix this issue, you should remove the unused import statement. Here’s the single line change to address the issue:

Suggested change

	import com.enonic.xp.inputtype.InputTypeProperty;
	import com.enonic.xp.inputtype.InputTypeProperty; // Remove this line

Alternatively, if you want to keep the import for future use, you could simply comment it out instead of removing it completely:

Suggested change

	import com.enonic.xp.inputtype.InputTypeProperty;
	// import com.enonic.xp.inputtype.InputTypeProperty; // Comment out this line

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium UnusedCode issue: Unused import - com.enonic.xp.inputtype.InputTypeConfig.

The issue reported by the Checkstyle linter indicates that the import statement for com.enonic.xp.inputtype.InputTypeConfig is not being used anywhere in the YmlFormParser class. Unused imports can clutter the code and may lead to confusion about which classes are actually necessary for the implementation.

To fix this issue, you should remove the unused import statement. Here’s the suggested code change:

Suggested change

	import com.enonic.xp.inputtype.InputTypeConfig;
	import com.enonic.xp.inputtype.InputTypeDefault;

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium UnusedCode issue: Unused import - com.enonic.xp.inputtype.InputTypeDefault.

The Checkstyle linter has identified that the import statement for com.enonic.xp.inputtype.InputTypeDefault is not being used anywhere in the YmlFormParser class. This means that the class does not reference or utilize InputTypeDefault, making the import unnecessary and contributing to code clutter.

To resolve this issue, you can simply remove the unused import statement. Here’s the suggested change:

Suggested change

	import com.enonic.xp.inputtype.InputTypeDefault;
	import com.enonic.xp.inputtype.InputTypeDefault; // Remove this line

---

This comment was generated by an experimental AI tool.

[codacy-production]

ℹ️ Codacy found a minor CodeStyle issue: Avoid unnecessary constructors - the compiler will generate these for you

The issue identified by the PMD linter is that the constructor public JsonSchemaRegistry() is unnecessary because the Java compiler automatically generates a default constructor if no other constructors are defined in the class. Since there are no additional initializations or parameters needed in the constructor, it can be removed to adhere to cleaner code practices.

To fix the issue, you can simply remove the explicit constructor. Here’s the code suggestion:

Suggested change

	public JsonSchemaRegistry()
	// public JsonSchemaRegistry() { }

This change effectively eliminates the unnecessary constructor, allowing the compiler to provide the default constructor implicitly.

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium BestPractice issue: Avoid unused private fields such as 'applicationKey'.

The PMD linter has identified that the private field applicationKey in the YmlFormParser class is declared but not used anywhere in the class. This can lead to code that is harder to maintain and understand, as it suggests that there may be unnecessary complexity or leftover code that serves no purpose.

To fix this issue, you can either remove the unused field if it's not needed, or if you plan to use it later, you can suppress the warning temporarily. However, since the request is for a single line change, the most straightforward fix is to remove the unused field altogether.

Here's the code suggestion to remove the unused applicationKey field:

Suggested change

	private final ApplicationKey applicationKey;
	// private final ApplicationKey applicationKey;

---

This comment was generated by an experimental AI tool.

[codacy-production]

⚠️ Codacy found a medium BestPractice issue: Perhaps 'applicationKey' could be replaced by a local variable.

The PMD linter is suggesting that the applicationKey field could potentially be replaced with a local variable, which may imply that the field is not being used beyond the constructor or that its usage could be more efficient. However, in this case, since applicationKey is likely intended to be used across multiple methods in the YmlFormParser class, it makes sense to keep it as a field. The suggestion from the linter may not be appropriate if the applicationKey is indeed necessary for the class's functionality.

If you are looking to address the PMD warning while still keeping the field, one way to do this is to use a local variable in the constructor and then assign it to the field. Here's how you can modify the constructor:

Suggested change

	private final ApplicationKey applicationKey;
	this.applicationKey = applicationKey;

However, since this is already how it's written, if you want to eliminate the PMD warning while keeping the same functionality, you could simply ignore the suggestion, as the field is likely necessary.

If you want to address the issue directly without changing the functionality, you could remove the field altogether and keep it as a local variable in the constructor if it is only used there. But in the context provided, it seems that retaining the field is more appropriate.

In summary, the original line private final ApplicationKey applicationKey; should remain as is, but if you want to satisfy the linter while keeping the class structure, you could consider the following suggestion:

Suggested change

	private final ApplicationKey applicationKey;
	private final ApplicationKey applicationKey; // Keep as is, but ensure it's used in the class.

If you decide to refactor and use a local variable instead (though this may not be advisable), you can modify the constructor like this:

Suggested change

	private final ApplicationKey applicationKey;
	ApplicationKey appKey = applicationKey; // Use a local variable instead (not recommended if used elsewhere).

Ultimately, the best approach is to evaluate the usage of applicationKey within the class and decide based on its necessity.

---

This comment was generated by an experimental AI tool.