Skip to content

Instantly share code, notes, and snippets.

@gaurabdg

gaurabdg/GSoC20-FinalReport-GaurabDasgupta.md

Last active September 1, 2020 21:17
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save gaurabdg/74b70bfffe73cc4be8120f9dbbac449c to your computer and use it in GitHub Desktop.
Save gaurabdg/74b70bfffe73cc4be8120f9dbbac449c to your computer and use it in GitHub Desktop.
Download ZIP
GSoC '20 Final Report for the Project - Generation of Metadata for all Modules at Checkstyle - Gaurab Dasgupta
Raw
GSoC20-FinalReport-GaurabDasgupta.md

Google Summer of Code '20 Final Report

Project - Metadata Files for all Modules

Student - Gaurab Dasgupta

Organisation - Checkstyle

Mentors - Roman Ivanov, Andrei Paikin, Daniel Mühlbachler-Pietrzykowski, Calixte Bonsart, Richard Veach

Problem Statement

Various projects need to use Checkstyle module(check/filter) metadata(e.g. module description/parent, properties default value, type, etc.) for their functioning. But as of now they have to maintain their own metadata which becomes time consuming and the onboarding process becomes cumbersome.

Who would Benefit?

  • IDE plugins: Sonarqube plugin, Eclipse IDE plugin, etc. who maintains module metadata manually.
  • Third Party Check Extensions: Companies/teams who needs to develop their own checks and configure them in the IDE plugins the same way standard checks are done. E.g. SevNTU checks

Solution

A library was developed which would generate metadata automatically from javadocs of modules(checks, filters, file filters), using an Abstract Syntax Tree created with the help of ANTLR and make it available to consumers who can use it as it is or modify if they want to. So, instead of creating and editing their own metadata, it just becomes a version bump in their config.

Benefits

  • Time saving - The check developer has to mention all the metadata only once i.e, while writing the checks. No need for the plugin developers to update and maintain separate metadata for each checkstyle release.
  • Consistency - All plugins will have access to the same metadata supplied by checkstyle.

Ways to Interface

  • Simple library calls - Plugin developers can easily get all the metadata from the single checkstyle dependency, as it is just another package in the checkstyle source code.
  • XML files - This is also made available for maintaining backward compatibility and giving the freedom of manually editing any data, if required.

Implementation and Work Done during GSoC

  • You can find all my work in the Pull Requests submitted to Checkstyle.

  • All the metadata generator code can be found in the meta package of checkstyle.

  • In addition to this, I have made library integration changes for

  1. Eclipse IDE Plugin
  2. Sonarqube Checkstyle Plugin

The Metadata Generation and Consumption Flow

  1. Module's class level javadoc is scraped for required metadata
  2. Metadata XML files are produced for all modules and packaged in the checkstyle JAR
  3. Plugins which have checkstyle as their dependency can read all available modules' metadata available in the classpath.
  4. Third party check extensions can simply supply a list of file paths pointing to their check source files and metadata will be produced for other plugins to consume similarly.

Checkstyle Codebase: Javadoc Scraper and XML File Interfacing Utilities

My commits(In the drop down)

Javadoc Cleanup and Modification for Scraping Support
Javadoc Scraper, Metadata POJOs and XML File Import/Export Utilities

NB: It was all along hosted in a temporary repo, these are the main code base merge PRs

Eclipse CS IDE Plugin

My commits

Sonarqube Plugin

My Commits

Ongoing Work and Further Improvements

Although the major part of the project is done, I am planning to continue working and provide useful additions.

PRs/Issues

  • Remaining UTs - Improve code coverage and pitest coverage. Along with that, there needs to be two important UTs to ensure smooth functioning of this library.

    1. Template Enforcing UT - Each module's class level javadoc needs to follow a certain template so that the scraper doesn't break.
    2. Consistent Metadata UT - We need to check whether the check's source code and javadoc metadata are consistent or not.

  • Plugin and check extension documentation

  • A more versatile tool implementation of the library - Write now the file generation part is being done by an UT. I am planning to later implement a better way of doing this. e.g. an ANT Task.

Acknowledgements

I would like to thank the Checkstyle team for giving me this amazing oppurtunity. I am immensely grateful to my mentors Roman Ivanov, Andrei Paikin, Daniel Mühlbachler-Pietrzykowski, Calixte Bonsart and Richard Veach who have been supporting me all through in successfully completing my project. I have been able to come a long way from starting off as a total beginner in the open source community≠ solely because of their guidance. I am looking forward to keep on contributing to this wonderful product to the best of my abilities.

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