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

Autoconfigure checkstyle by conventions #618

Open
mwisnicki opened this issue Aug 9, 2023 · 4 comments
Open

Autoconfigure checkstyle by conventions #618

mwisnicki opened this issue Aug 9, 2023 · 4 comments

Comments

@mwisnicki
Copy link

It would have been nice if $projectDir/config/checkstyle/checkstyle.xml was automatically picked up from project.

@jshiell
Copy link
Owner

jshiell commented Aug 24, 2023

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.

@mwisnicki
Copy link
Author

mwisnicki commented Aug 25, 2023

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.

@jshiell
Copy link
Owner

jshiell commented Aug 25, 2023

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 checkstyle.xml in the project root, or in etc as Ritchie intended). But that's the easy part, iterate over a list of locations.

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 git pull? What if it's on a network drive and suddently gets added/removed by another user? In short, there's lots of edge cases that need to be considered to make the feature work in a predictable, sensible way for the majority of users.

@mwisnicki
Copy link
Author

Ideally should be observed but suspended around git operations.
If that's too hard/too much work then just have reload action somewhere.
Same as gradle, maven and other integrations.

Missing arguments and other problems don't have to be handled - presumably they will cause a filure.

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

No branches or pull requests

2 participants