Skip to content

Issue #13422: Implement module violation messages macro #13423

Merged
romani merged 1 commit intocheckstyle:masterfrom
stoyanK7:13422
Aug 3, 2023
Merged

Issue #13422: Implement module violation messages macro #13423
romani merged 1 commit intocheckstyle:masterfrom
stoyanK7:13422

Conversation

@stoyanK7
Copy link
Copy Markdown
Contributor

Resolves #13422

@stoyanK7 stoyanK7 marked this pull request as ready for review July 26, 2023 16:36
Copy link
Copy Markdown
Contributor

@nrmancuso nrmancuso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Items, some are contingent on response at #13423 (comment) :

*/
private static Set<String> getMessageKeys(Set<Field> messageKeyFields, Object instance)
throws MacroExecutionException {
final Set<String> messageKeys = new TreeSet<>();
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why TreeSet?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

final Set<Field> fields = CheckUtil.getCheckMessages(clss, true);
final Set<String> list = new TreeSet<>();
for (Field field : fields) {
// below is required for package/private classes
field.trySetAccessible();
list.add(field.get(null).toString());
}

Copy link
Copy Markdown
Contributor

@nrmancuso nrmancuso Jul 29, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, why are we forced to use Set at all? Do we want to maintain insertion order? If so, we should use LinkedHashSet.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No duplicates are allowed in messages

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be good to order alphabetically in html.

It is already done in ViolationMessagesMacro::createListOfMessages

        Collections.sort(messageKeys);

Copy link
Copy Markdown
Contributor

@rnveach rnveach Aug 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rnveach awesome explanation, thanks a lot. @stoyanK7 please restore copy pasta and add a comment about why we use treeset

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nrmancuso Done at #13505.

@nrmancuso nrmancuso assigned rnveach and unassigned nrmancuso Jul 31, 2023
@nrmancuso
Copy link
Copy Markdown
Contributor

I would like to make sure we have response from @rnveach at #13423 (comment) before we merge.

Copy link
Copy Markdown
Member

@romani romani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Items

Copy link
Copy Markdown
Member

@romani romani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Items

@stoyanK7 stoyanK7 mentioned this pull request Aug 1, 2023
17 tasks
Copy link
Copy Markdown
Member

@romani romani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Items

final Object instance = SiteUtil.getModuleInstance(checkName);
final Class<?> clss = instance.getClass();
final List<String> messageKeys = SiteUtil.getCheckMessageKeys(clss, instance);
createListOfMessages((XdocSink) sink, clss, messageKeys);
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we are leaving this in production, then why don't we remove the test code and have it use this instead?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code is still planned to be moved to separate project. I am ok with such transitional copy paste of utils.

Copy link
Copy Markdown
Member

@romani romani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok to merge

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement module violation messages macro

4 participants