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
Support Multiple Configuration Files #991
Comments
That issue will be considered after moratorium period, as it require serious changes. List of problems/tasks:
Google's config is 1/3 of all Checks, we will offer user more to force him to use custom config.
Few projects, each of them will use base configuration that is inside a jar, and some custom config file that is specific to each project. OK , make sense. |
@romani I am bringing this issue back up.
I think this issue should only concern itself with allowing multiple, separate configurations to be run. Issue #2873 already started a discussion of inheritance for configurations and I think it requires many changes to the configuration to allow fine granularity of changing things. For this, I think we should allow running multiple configurations, one after the other, with the same set of files passed in through the CLI. It would allow us to chain multiple configurations together while only scanning the directories for files once. |
So are multiple configuration files going to be supported? |
@danon , please share your use-case of multiple configuration files. |
I don't need any inheritance/override. I would like to have separate files, like so: checkstyle_lint_rules_functions.xml
checkstyle_lint_rules_string.xml
checkstyle_lint_rules_indents.xml
checkstyle_lint_rules_misc.xml simply to separate rules into files. I would expect checkstyle to simply sum the rules into one Kinda like |
Look at how DTDs ENTITY feature can be useful for you, example https://android.googlesource.com/platform/prebuilts/checkstyle/+/master/android-style.xml . |
@romani see my reason why at #991 (comment) . I think this is why I personally can't use ENTITY loading. These regular expressions are specialized for the file type and combining them with the wrong types will create false positives. |
So requests are very different: @rnveach looks like interested in approach to use different configs BUT to reuse checkstyles scanning of files and content load (parsing of java files). This was originally requested in issue. Chaining of configs is reasonable also but probably it is better to implement it in plugins(ant, maven, eclipse). As in Checkstyle we have all under Checker module, so all parsed/loaded files are under its instance. Second config will mean separate Checker instance, so nothing will be shared. Sharing of content is "blocked" by Multithread mode discussion. Lets create separate issue on this, and collect ideas there. NOTE: we might make something like PMD have for including content from another file - https://github.com/checkstyle/checkstyle/blob/master/config/pmd-main.xml#L12 but it will help @danon , not @rnveach . But problem is that we have Treewalker module in config and some rules/checks/modules are under Checker or Treewalker. Simple include will not be possible, but we can invent new config format that will contain only modules for include (as defined by user) under Checker or TreeWalker in main config. If you both agree on such idea, lets create separate issue on this. |
@romani any way of splitting config into separate files would be great, so I'm ok with this :) |
Please share a reason of split, without reason we unlikely do anything. |
re-use scanning of files only. The files are all different types, so there is no more Java files after the other configs. Example file types are Java, properties, XML, and JSP. I don't expect anything to be shared between multiple configs.
No. Merging the configs into 1 will cause issues with regular expression checks like I mentioned before. A expression for 1 file type won't work for another.
I personally don't use plugins. Just checkstyle directly at this time. My project hasn't switched to Maven yet. |
I also don't use plugins, I like my project clean and without any redundancies (for now). Loading rules from multiple files would really help me. Or even a single rule <include file="check_style_custom.xml"/>
// or
<additional-rules file="check_style_custom.xml"/> would be enough. |
Please explain a reason to split config in multiple files. Right now we are and more focused to allow have all in one config file ( for good reason). your reason is still unclear for me, I see no benefits. |
Please create new issue on this to support by CLI only. We will discuss exact names and workflow.
It is separate mode, user will be responsible for all conflicts. We will provide ability to do this, user should think on how to override properly to get required result. It will not be solution for all cases, but it will help to slightly modify Google config without coping of it . |
Maybe I am confused, but we are discussing a new issue for running multiple configurations in Checkstyle, right?
This issue was never about inheritance, if this is what you mean by "override". There is another issue on that. I am just literally looking for running multiple configs side by side with the same list of files scanned. |
discussion is moved to #6942 for chaining of configs. |
I would like support for running with multiple configuration files.
Example: java com.puppycrawl.tools.checkstyle.Main -c /google_checks.xml -c /custom_checks.xml
I tried this in 6.5 and it only run the first check and ignored the second.
I see this as useful if we want to add our own custom checks to be run alonside a standard one, like google's. The current way around this would be to copy the google xml and append new checks to the end of it, but then we would be required to do this for every project. The configurations in jar are there so we don't have to keep reproducing it. Not to mention if the original xml should be updated, this would require me to update the custom xml, along with the jar.
There are also other times where I can't put all my checks in the same file because of the "RegexpSingleline" module where I want to run different regular expressions on different file types. Having them all in the same configuration on all file types will produce incorrect errors because some checks are only made for one type, and it is allowed in another. I could run checker twice with the different configurations, but that is extra work and time going through the directory tree multiple times.
The text was updated successfully, but these errors were encountered: