-
Notifications
You must be signed in to change notification settings - Fork 156
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
Autoconfigure checkstyle by conventions #618
Comments
Checking for common locations is a potential feature, but unlikely due to knock-on effects at present - e.g. how do we manage these locations? Do we need to check them and add/remove them when the file appears/disappears? If we don't clean up, how do we handle errors? If another file is selected, do we override that if this file appears? I'm not convinced it's worth the effort at present, especially given the variety of locations where people do keep the files. |
I don't think I understand your concern. There is only one location. If file is present just add it. If missing remove it. If the user doesn't like that they can rename the file. |
You have only one location - but if a feature like this is implemented it'd be dadt not to cover more common locations (e.g. people often put The bigger problem is we're changing the contract - at present, you add the file and you manage it. If we start autodetecting, we pick up all the management problems - e.g. what if the file is removed, or if the file requires parameters to be entered and hence we can't run it without user input? And we can't just add it - e.g. when would we add it? Just check at project startup? What if the file appears - or disappears - after a |
Ideally should be observed but suspended around git operations. Missing arguments and other problems don't have to be handled - presumably they will cause a filure. |
It would have been nice if
$projectDir/config/checkstyle/checkstyle.xml
was automatically picked up from project.The text was updated successfully, but these errors were encountered: