Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RAT-355: Add configuration dump to report #205

Conversation

Claudenw
Copy link
Contributor

Closes Rat-355.

Adds CLI options.

--list-licenses all|approved|none (default: none)
--list-families all | approved | none (default: none)
--dry-run

if either of the --list-X options is not "none" the reporter will add a "rat-config" section to the report XML document. This section has the same structure as the XML configuration file.

if --dry-run is specified then no files are updated and no files are scanned.

@ottlinger ottlinger changed the title Rat-355 add configuraiton dump to report RAT-355: Add configuration dump to report Jan 21, 2024
}

public static Inspector license(ILicense license, Inspector matcher) {
return new AbstractInspector(Inspector.Type.License, "license") {
Copy link
Contributor

Choose a reason for hiding this comment

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

Would one want to extract all of these license-config-related constants into a class where we could easily add documentation about the semantics of each option/value/parameter?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The parameters for the XML output should all be defined in the documentation about the XML configuration file. That is partly done. I opened a ticket about it. I have some questions about how to go about documenting things that span the various UIs.

Copy link
Contributor Author

@Claudenw Claudenw Mar 15, 2024

Choose a reason for hiding this comment

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

The problem (for reporting) is that the current system allows creation of new IHeaderMatcher types and adding those matchers to the system. This means that the output has to be able to handle matchers that we don't know about yet.

I think the way to approach this might be to have each system class that represents an item in the have a getDescription() method that will return a Description that is basically the same as the Inspector, but is defined within the class. This will handle the new class problem noted above, as well as provide a mechanism to construct documentation for all the options and/or display that information to the user.

I have an example of the Description approach.

@Claudenw Claudenw force-pushed the RAT-355_Add_Configuraiton_dump_to_report branch from 23f08ae to baca8d4 Compare January 21, 2024 22:31
@Claudenw
Copy link
Contributor Author

Closing in favor of #227 which has a better solution

@Claudenw Claudenw closed this Mar 28, 2024
@Claudenw Claudenw deleted the RAT-355_Add_Configuraiton_dump_to_report branch April 23, 2024 15:32
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.

2 participants