-
Notifications
You must be signed in to change notification settings - Fork 59
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
[BUG] Java Doc warnings with gradle check #496
Comments
@saratvemulapalli do you think we can add |
There are no errors. These are warnings. This needs to be more of a discussion before we say it's a good first issue.
We specifically put in the "RequireJavadoc" dependency to allow for exceptions in exactly these circumstances. I opened an issue on OpenSearch outlining much of this same reasoning. See #4541. I am removing the good first issue tag until we decide if we really really really want boilerplate getter and setter comments and want to force everyone to create no-arg constructors just to javadoc them with "creates an instance of the class that is documented with the class javadoc up there". |
In case you don't follow the link in the comment listed above, this is what you want if you want to make these errors |
Also relevant, the discussion on #27 where I thought I had consensus on the "don't do trivial javadocs" front, otherwise I would have put in stricter checks 8 months ago and not gotten here. Another option is to use checkstyle for javadoc checking. That's what i do on my other repos that I maintain. It's far more configurable, and even catches some cases the existing setup misses. I had avoided it before because the main purpose of checkstyle is duplicated by spotless and it's a heavy dependency, but I'd rather use a screwdriver on a swiss army knife than a single purpose sledgehammer. :) |
Haha thats true. Its all warnings, I prefer to get the warnings away :).
That makes sense, I agree we could discuss this and vote for options folks would prefer. |
We can use If you agree I would like to take this task so it won't throw any warnings while running in |
We already do that (in fact I'm the one who asked for that feature!) opensearch-sdk-java/build.gradle Lines 129 to 133 in 30759d2
Unfortunately, RequireJavaDoc only tests for the presence or absence of a javadoc. We still need to use the JDK's doclint tool to test for the correct javadoc. And all this works better on earlier JDKs but starting with JDK 18, the doclint was changed to add more warnings, which is what we are seeing.
If you'd like to take on this task, that's fine, but I think as-of JDK 18, we might want to remove the RequireJavadoc and doclint configuration and use a completely different setup. Checkstyle does javadoc checking (and a ton of other stuff) and is a lot more configurable, inclding allowing suppression of "trivial" properties. See https://checkstyle.sourceforge.io/config_javadoc.html I use it on another project I maintain, sample config here (not suggesting to copy it directly, but just an example): https://github.com/oshi/oshi/blob/ccce731ddae489d1541da31d678d3e2e290d985c/config/checkstyle.xml#L314-L320 |
We could also use checkstyle to fail on star imports that we've also hacked into spotless. |
We have removed CheckStyle from OpenSearch to have just formatting tool i.e. Spotless. IMO we should avoid doing the same for SDK. |
I'd like a better reason to not use CheckStyle than "have only spotless" because in fact, OpenSearch has multiple tools:
Spotless doesn't do Javadocs. We need a tool to do javadocs. We are currently using a mix of tools that this issue has identified as insufficient. I'm not suggesting to use Checkstyle for formatting. I'm suggesting using it to plug in the gaps where Spotless falls short, which include:
Other than "we only want one formatting tool" what is the opposition to using checkstyle for things that aren't formatting? |
|
Since we are not using CheckStyle for formatting and only for styling purpose, I'm fine with it. Security plugin is doing the same. |
And a lot more checks I see. We can consider adding some of those in over time. And also consider spotbugs (leaning yes) and/or PMD (leaning big no) at some point. |
I like spotbugs! |
What is the bug?
Gradle check throws a bunch of java doc warnings.
How can one reproduce the bug?
./gradlew check
What is the expected behavior?
No errors :)
What is your proposed fix?
There are 2 parts to this issue:
The text was updated successfully, but these errors were encountered: