Skip to content

Issue #13626: Reuse in metadata module scrapper all methods to get data from javadoc and reflection only#13670

Closed
stoyanK7 wants to merge 1 commit intocheckstyle:masterfrom
stoyanK7:13626
Closed

Issue #13626: Reuse in metadata module scrapper all methods to get data from javadoc and reflection only#13670
stoyanK7 wants to merge 1 commit intocheckstyle:masterfrom
stoyanK7:13626

Conversation

@stoyanK7
Copy link
Contributor

Resolves #13626

@nrmancuso
Copy link
Contributor

@stoyanK7 let's rebase and prepare for review :)

Copy link
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:

@romani romani removed the blocked label Sep 2, 2023
Copy link
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

@romani romani marked this pull request as ready for review September 4, 2023 16:50
Copy link
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

import javax.xml.parsers.ParserConfigurationException;
import javax.xml.transform.TransformerException;

import org.apache.maven.doxia.macro.MacroExecutionException;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It isn't ideal that the metadata module uses the site module. I think it's better if the opposite is the case - the site module uses the metadata module. Shall we deal with this in a follow-up issue?

Copy link
Member

Choose a reason for hiding this comment

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

We will refactor later on to move methods around to make it better design wise.
For now let's focus on functionality to unblock ability to remove properties from javadoc

Copy link
Member

Choose a reason for hiding this comment

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

Let's collect ideas at #13699 to improve in separate PRs

@romani
Copy link
Member

romani commented Sep 4, 2023

I think PR is ready to not have commit for disablement of CIs, please remove.
Let's finalize initial version of metadata scrapper from javadoc only.

Please rephrase commit message, as you do not rewrite but you change a way we get data and we will do this very gradually.

@stoyanK7 stoyanK7 changed the title Issue #13626: Rewrite metadata module Issue #13626: Reuse in metadata module scrapper all methods to get data from javadoc and reflection only Sep 4, 2023
* @param propertyJavadoc property javadoc.
* @return property description.
*/
private static String getPropertyDescription(String property, DetailNode propertyJavadoc) {
Copy link
Member

@romani romani Sep 4, 2023

Choose a reason for hiding this comment

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

I am not sure why this method is specific for metadata.
I think there should single method that does it for xdoc and meta and meta generation just reuse it
Same for getPropertyDefaultValue

If agree please create separate issue to improve in separate PR

Copy link
Member

Choose a reason for hiding this comment

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

If you agree add it to #13699

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think there should be separate methods for xdoc and metadata. Or at least single method with different output depending on who/what is calling it.

Metadata gets text as-is and doesn't care about any processing.

Xdoc requires to

  • convert {@code something} to <code>something</code>
  • Convert links to relative ones- https://checkstyle.org/checks/block/xxx.html -> ../block/xx.html, for example

Copy link
Member

Choose a reason for hiding this comment

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

But still data creation should be single method and xdoc just do only such required formatting. If you agree just put this to separate issue that we have for design improvement as item.

Copy link
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 to unblock massive removal of javadoc content.
We will improve in separate PRs

@romani
Copy link
Member

romani commented Sep 4, 2023

@stoyanK7 , please make CI green.

Copy link
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:

<exclude>
com.puppycrawl.tools.checkstyle.api.AutomaticBean*
</exclude>
<exclude>com.puppycrawl.tools.checkstyle.meta.MetadataGeneratorUtil</exclude>
Copy link
Contributor

Choose a reason for hiding this comment

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

@romani should we create an issue for coverage in this class and revisit later?

Copy link
Member

Choose a reason for hiding this comment

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

This is jacoco coverage.
The only time it makes sense if we ever move all functionality to separate project and we remote xdoc files from git completely, as we will never see how content looks like before html generations.
Before this time, all such methods should not have to work on all possible cases, code should serve our current cases of Checks and xdoc/meta. So coverage has no much meaning.
Do we need such issue ? As we do not even has plan to move it out

Copy link
Member

Choose a reason for hiding this comment

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

If you agree, please copy my comment or part of it to description at #13426 as requirements

Comment on lines +50 to +53
/** No-argument constructor. */
public ModuleDetails() {
// empty constructor
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Why do we need this?

Copy link
Member

Choose a reason for hiding this comment

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

Compile error https://stackoverflow.com/a/5286532/1015848
We still have old code of metadata that use default ctor.

We are not rewriting metadata, we migrate it to use new method to get data that are based on reflection and javadoc

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There is usage of it in JavadocMetadataScraper

Comment on lines +43 to +46
/** No-argument constructor. */
public ModulePropertyDetails() {
// empty constructor
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Same as above, why do we need this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same as above

final ModulePropertyDetails modulePropertyDetails = new ModulePropertyDetails();

Lists.reverse(Arrays.asList(detailNode.getChildren())).forEach(stack::push);

final String childText = detailNode.getText();
// Regular expression for detecting ANTLR tokens(for e.g. CLASS_DEF).
Copy link
Contributor

Choose a reason for hiding this comment

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

Unless I am missing something, we are not doing anything with ANTLR tokens, ANTLR is an internal detail of parser/AST implementation. Outside of these usages, these just become JavadocTokenTypes.

Copy link
Contributor

Choose a reason for hiding this comment

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

Can we just use

public static Map<String, Integer> nameToValueMapFromPublicIntFields(Class<?> cls) {
to get a list of actual tokens and check that?

Comment on lines +123 to +124
final Path templatePath = SiteUtil.getTemplatePath(
SiteUtil.removeCheckSuffix(SiteUtil.getModuleName(file))
Copy link
Contributor

Choose a reason for hiding this comment

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

We are getting crazy with utility method usage and creation. Why can't we do a simple replace with Check as target?

* @param moduleName module name.
* @return module type.
*/
private static ModuleType getModuleType(String moduleName) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean make the one in JavadocMetadataScraper public?

Copy link
Contributor

Choose a reason for hiding this comment

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

I have no strong feelings either way, but we should consider some way to avoid massive copy paste


final String childText = detailNode.getText();
// Regular expression for detecting ANTLR tokens(for e.g. CLASS_DEF).
final Pattern tokenTextPattern = Pattern.compile("([A-Z_]{2,})+");
Copy link
Contributor

Choose a reason for hiding this comment

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

Why compile this pattern repeatedly? Can we make this a field? Even better, can we just use

public static Map<String, Integer> nameToValueMapFromPublicIntFields(Class<?> cls) {
to get the actual tokens?

Comment on lines +1130 to +1138
final Set<Path> templatesPaths = SiteUtil.getXdocsTemplatesFilePaths();
for (Path templatePath: templatesPaths) {
final String content = getFileContents(templatePath);
final String propertiesMacroDefinition = "<macro name=\"properties\"";
if (content.contains(propertiesMacroDefinition)) {
result.add(templatePath);
}
}
return result;
Copy link
Contributor

Choose a reason for hiding this comment

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

psuedocode:

return SiteUtil.getXdocsTemplatesFilePaths().stream()
    .map(SiteUtil::getFileContents)
    .filter(c -> c.contains(p))
    .collect(Collectors.toList());

}

/**
* Get validation type for the given property.
Copy link
Contributor

Choose a reason for hiding this comment

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

What is a validation type?

Copy link
Member

@romani romani Sep 6, 2023

Choose a reason for hiding this comment

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

Actual type is int[] but business logic wise it is int values from "enum"-like class of tokens. So this helps plugins to know how to validate content. Ideally it should be hinted by source code but we never end up doing it explicitly.

Only for tokens https://github.com/search?q=repo%3Acheckstyle%2Fcheckstyle+validation-type&type=code&p=1

Set<String> properties, Map<String, DetailNode> javadocs,
String className, Object instance)
throws MacroExecutionException {
final List<ModulePropertyDetails> result = new ArrayList<>(properties.size());
Copy link
Contributor

Choose a reason for hiding this comment

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

result -> modulePropertyDetails

@rnveach
Copy link
Contributor

rnveach commented Sep 7, 2023

@stoyanK7 Since we are re-writing meta, did you verify if any of your changes will break eclipse-cs or sonar?

@romani
Copy link
Member

romani commented Sep 9, 2023

We are not rewriting, we are using different approach to get data for metadata files that we generate. No changes in files, it means it works as before.

@romani
Copy link
Member

romani commented Mar 16, 2024

very sad that me failed to merge this, issue is still open, I hope we can come back to it.

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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Reuse in metadata module scrapper all methods to get data from javadoc and reflection only

4 participants