Issue #13422: Implement module violation messages macro #13423
Issue #13422: Implement module violation messages macro #13423romani merged 1 commit intocheckstyle:masterfrom stoyanK7:13422
Conversation
src/main/java/com/puppycrawl/tools/checkstyle/site/XdocsTemplateSink.java
Outdated
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Items, some are contingent on response at #13423 (comment) :
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
| */ | ||
| private static Set<String> getMessageKeys(Set<Field> messageKeyFields, Object instance) | ||
| throws MacroExecutionException { | ||
| final Set<String> messageKeys = new TreeSet<>(); |
There was a problem hiding this comment.
We want to preserve the order of the keys. Using HashSet messed up the order and failed XdocsJavadocsTest. That's what's being done in XdocsPagesTest
checkstyle/src/test/java/com/puppycrawl/tools/checkstyle/internal/XdocsPagesTest.java
Lines 1381 to 1389 in 0c2ab53
There was a problem hiding this comment.
Hm, why are we forced to use Set at all? Do we want to maintain insertion order? If so, we should use LinkedHashSet.
There was a problem hiding this comment.
I got rid of the Set and just used a List.
@rnveach could you please tell if using a Set here is a must? Could there be some duplicates or?
There was a problem hiding this comment.
No duplicates are allowed in messages
There was a problem hiding this comment.
Set, will hide duplicates to make illusion in html.
Better to use List to simply print as is.
The only extra benefit from fancier collection I see, is ordering.
It will be good to order alphabetically in html.
But we can do this later on, after transition to templates is done.
There was a problem hiding this comment.
It will be good to order alphabetically in html.
It is already done in ViolationMessagesMacro::createListOfMessages
Collections.sort(messageKeys);There was a problem hiding this comment.
You can't use a collection that is based on hashcode. It is JVM specific and different runs can generate different hashes and orders. We can't use insertion order here because reflection is not guaranteed an order and we want to ensure our documentation is consistent in order. It will be bad if one run says A,B,C and then another run says C,A,B. This is why we originally used TreeSet, to say order is alphabetic.
I recommend keeping this a copy/paste and just create new issues to fix anything.
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
|
I would like to make sure we have response from @rnveach at #13423 (comment) before we merge. |
src/main/java/com/puppycrawl/tools/checkstyle/site/ViolationMessagesMacro.java
Outdated
Show resolved
Hide resolved
| final Object instance = SiteUtil.getModuleInstance(checkName); | ||
| final Class<?> clss = instance.getClass(); | ||
| final List<String> messageKeys = SiteUtil.getCheckMessageKeys(clss, instance); | ||
| createListOfMessages((XdocSink) sink, clss, messageKeys); |
There was a problem hiding this comment.
So what is the plan in terms of disabling javadoc. Are we not going to have these type of generation in meta and have our macros get the data from meta? To me this makes the most sense, instead of meta having another custom implementation.
There was a problem hiding this comment.
This implementation will substitute getting data from metadata.
For now validation javadoc vs xdoc help to test this implementation until it gets its maturity.
Such "another implementation" will me main implementation and source of truth soon.
| * A macro that inserts a list of the violation messages. | ||
| */ | ||
| @Component(role = Macro.class, hint = "violation-messages") | ||
| public class ViolationMessagesMacro extends AbstractMacro { |
There was a problem hiding this comment.
So we are not going to disable the violation portion of the xdocspages test for classes we have converted to use macros to show it isn't needed anymore?
There was a problem hiding this comment.
Not for now, but as we convert all modules to templates, and all continue to match, we can disable it. May be we will make some hack to allow migration suppression for such validation.
| /** | ||
| * Utility class for site generation. | ||
| */ | ||
| public final class SiteUtil { |
There was a problem hiding this comment.
If we are leaving this in production, then why don't we remove the test code and have it use this instead?
There was a problem hiding this comment.
This code is still planned to be moved to separate project. I am ok with such transitional copy paste of utils.
Resolves #13422