Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
ImportControl should have property which allows to validate specified file path #3462
ImportControl should have parameter (atribute for
Example of how to configure the check to validate only classes which are located in com.puppycrawl.tools.checkstyle package and which file path matches
<import-control pkg="com.puppycrawl.tools.checkstyle" path="^.*[\\/]main[\\/].*$"> ... <allow class="com.google.common.base.CaseFormat" local-only="true"/> ... </import-control>
In documentation we need to show how to make two configurations for
In scope of this issue we need to split configuration into two and make rules for
This will allow us to restrict usage of Guava library (#3433) in main code and keep freedom to use convenient methods in test area.
changed the title from
ImportControl should have parameter which allows to validate specified scope: test or main
ImportControl should have parameter which allows to validate specified file path
Sep 23, 2016
referenced this issue
Sep 29, 2016
referenced this issue
Sep 30, 2016
added a commit
Dec 4, 2016
This functionality could be achieved by adding a
Should I skip over files that don't match the pattern in
I would do the matching in
It would be nice if
Yes, it is no different than AbstractFileSets which choose any specific files to look at, example TranslationCheck. It just needs to be documented to user.
This is what we usually work with, this is why the pattern is regular expression and must be a very distinct area. See OuterTypeFilenameCheck.
It sounds good to me as long as the requirements don't change.
Just my thoughts on this issue.
@romani I am against 2 configuration files for various reasons. This will double the amount of time a full run will take since we don't support 2 configurations in 1 run (double listing files, double parsing, etc). It is also more tenuous to keep 2 different configurations in synch, especially if users want same checks in both areas, like us. This will also require our cache to be split into 2 files to avoid conflicts.
Something like this would increase the burden on us and other users for maintainability, imo.
Is it not reasonable to set the file path either on the
no way, it will be a problem for mode when checkstyle is running in IDE.
yes. Check should do all to optimize his performance.
No, that is change in API and not really required. beginTree --> false - mean nothing. That method is event, what you/Check do with event is custom Check business.
yes, I am against too.
It is better to have two
@romani OK, I will make example configs based on Checkstyle's
Regarding the name for the attribute/tag, I think
please do no go crazy with, we just need mock view (it should not work).
Yes, root element is only one by DTD - https://www.w3.org/TR/REC-xml/#dt-root
Lets have a look.
I have quickly made some example configurations based on
Personally I prefer having a
your confis in short:
I do not like
@rnveach , please share your ideas
I give 1 and 3 the same level of approval. To me they are the same as a blocked
In terms of ranking between 1/3 and 2, to me it really depends on how dramatically different the list of imports are. I know you like separating test from production, but is the differences between the 2 configs going to be that big? Right now, only complaint is guava and I am only seeing this once in the examples given. If everything else will be the same between the 2, then it puts more work on us to keep them in synch. So for our current use, I would rank 1/3 as higher.
I do have one additional option to present that I didn't think of before. We'll call this option 4.
Terms of ranking, I still group this with 2 and but see it as slightly higher than 2.
Final results: 1/3, 4, 2.
sorry , main attributes were missed that diff main vs test. I updated my comment.
there should no limitations for guava and any other imports usage. There should be only
Yes I forgot the attributes. I updated my Gist as well.
My personal preference: option 1, then option 2 and lastly option 3.
If I were to choose I would opt for the 4th option now as it completely separates test config and production. For example, I always do such thing with Spring Boot and Spring configuration itself at work, and it works pretty well. All test configs are located in test-resources folder and it is clear enough for team members what are they for. On the other hand, programmers tends to be lazy
1st option also looks confusing to me. I did not understand the idea of the option when I had read the config at first. I don't want to examine the documentation and try to figure out what is
The 3rd option looks good, but ...
Lets back to the main idea of the issue:
Thus, the point is to separate two areas of the validation: test and main. The configuration of the check for the main area should be more strict than for the test area. Lets keep the main config in separate file and do not mix it with test config.
My final decision is 4, 3, 2, 1.
What should the property name be? I don't like
<module name="ImportControl"> <property name="file" value="import-control-test.xml"/> <property name="path" value="^.*[\\/]test[\\/].*$"/> </module> <module name="ImportControl"> <property name="file" value="import-control-main.xml"/> <property name="path" value="^.*[\\/]main[\\/].*$"/> </module>
The documentation must of course explicitly state that it is regex only.
added a commit
Jan 11, 2017
I am implementing this. I added unit tests to
What should I do about this? Should I create a new test containing only the tests for the
Maybe tests should be excluded from the MethodCount check?
ok to suppress MethodCount at for UTs and ITs - https://github.com/checkstyle/checkstyle/blob/master/config/suppressions.xml#L30.