[
https://issues.apache.org/jira/browse/SOLR-16346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17608883#comment-17608883
]
Jason Gerlowski commented on SOLR-16346:
----------------------------------------
Still not sure why Mike sees this behavior, but it seems patently wrong.
Taking the Jackson deps as an example, we declare jackson-core,
jackson-annotations, and jackson-databind right
[here|https://github.com/apache/solr/blob/main/solr/core/build.gradle#L147].
(Unless I've been misunderstanding what "usedUndeclared" means each time I've
seen it.)
> Generate (and use) OpenAPI spec for v2 APIs
> -------------------------------------------
>
> Key: SOLR-16346
> URL: https://issues.apache.org/jira/browse/SOLR-16346
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Components: v2 API
> Affects Versions: main (10.0)
> Reporter: Jason Gerlowski
> Assignee: Jason Gerlowski
> Priority: Major
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> An integration with [OpenAPI|https://www.openapis.org/] and its tooling has a
> lot to offer Solr. Once generated, an OpenAPI specification can be used to:
> * [generate clients|https://github.com/OpenAPITools/openapi-generator] for
> multiple programming languages
> * power a web UI to document and help users craft API calls (e.g.
> [redoc|https://github.com/Redocly/redoc]
> * [detect breaking API changes|https://github.com/Azure/openapi-diff] across
> releases.
> Of course, these benefits are only useful if we take pains to document our
> API inputs and outputs (probably with annotations that live directly in our
> Java code). But I think there's enough upside to be worth that trouble.
> This ticket aims to cover integrating OpenAPI into our gradle build, so that
> a single task can be used to generate an OpenAPI spec. (It might also make
> sense to use this ticket to cover generating client bindings for one or more
> languages.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
