Clean openApiGenerate output dir before generating #2502
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit fixes a problem in the Solr build whereby files generated from our OpenAPI spec could "leak" between branches and cause compilation issues. In short, generated SolrRequest implementations were not being overwritten or cleaned up after switching branches. This caused compilation problems whenever the new branch didn't have other classes (typically 'model' POJOs) that the generated file relied on. This commit uses the openApiGenerate task's "cleanupOutput" option to prevent this from happening.
dsmiley
approved these changes
Jun 6, 2024
There was a problem hiding this comment.
It's "safe" and will reduce user annoyance (as I've experienced / felt) so I approve.
I don't know if there is a notable negative performance impact, as there would be if this was a java compiler, which knows not to re-generate unchanged things. Update: I did a little trivial experimentation just now with this and I don't think it's a big concern.
|
This looks good to me. It will be even better when OpenAPITools/openapi-generator#17380 is fixed, which will stop the task from running as often as it is (the task will be skipped since the input & output will be unchanged). |
gerlowskija
added a commit
that referenced
this pull request
Jun 7, 2024
This commit fixes a problem in the Solr build whereby files generated from our OpenAPI spec could "leak" between branches and cause compilation issues. In short, generated SolrRequest implementations were not being overwritten or cleaned up after switching branches. This caused compilation problems whenever the new branch didn't have other classes (typically 'model' POJOs) that the generated file relied on. This commit uses the openApiGenerate task's "cleanupOutput" option to prevent this from happening.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Before compiling SolrJ, the gradle build creates an OpenAPI Spec ("OAS") describing our JAX-RS v2 APIs and then uses that spec to generate SolrRequest ".java" files. The responsible task (
solr:solrj:openApiGenerate) adds newly generated code tosolrj/build/generated, but it doesn't (by default) wipe the directory at the start of each invocation.This can cause generated files to "leak" across branches - sticking around in
solrj/build/generatedeven when the developer has changed to a branch that shouldn't contain the file.These leaks can cause compilation issues, as pointed out by @dsmiley recently on the dev list.
Solution
The solution is to have the
solr:solrj:openApiGeneratetask clear its output directory each time it runs. Luckily the OpenAPI tooling supports this, and it's a one-line change in build.gradle.Tests
Manual build testing.
Checklist
Please review the following and check all that apply:
mainbranch../gradlew check.