[Feature Request] [Gradle Checks] Allow annotation of InternalApi on classes not meant to be consumed outside of OpenSearch

[gbbafna]

Is your feature request related to a problem? Please describe

Coming from #13275 (comment)

RemoteStorePathStrategy is an internal API and is not supposed by to used/extended by plugins . However we can't mark it internal api .

error: The element org.opensearch.index.remote.RemoteStorePathStrategy is part of the public APIs but is marked as @InternalApi (referenced by org.opensearch.index.IndexSettings) 

error: The element org.opensearch.index.remote.RemoteStorePathStrategy is part of the public APIs but is marked as @InternalApi (referenced by org.opensearch.index.snapshots.blobstore.RemoteStoreShardShallowCopySnapshot) 

RemoteStorePathStrategy's constructor has to be public as RemoteStoreShardShallowCopySnapshot needs to create it .

Some more context : #13244

To get around these issues, all the classes we introduced had to marked as PublicAPI , even though they were not meant to be consumed outside of OpenSearch. Whenever we make changes to these classes, the detect breaking changes workflow will fail , even though these are not consumed outside of OpenSearch core.

Describe the solution you'd like

In cases like this, we should allow the class/function etc to be marked as InternalApi.

Related component

Build

Describe alternatives you've considered

Do nothing . In such cases such classes will be PublicApi and we will get a lot of breaking changes, even they are not actually.

Additional context

No response

[reta]

@gbbafna thanks, as we discussed, the scope of the suggested change is to support the @InternalApi on constructors to highlight the fact that instantiation of that particular type is not supposed to be done by outside of the OpenSearch.

The @PublicApi / @ExperimentalApi / ... annotations are required to any type that is exposed through to the plugins or/and extensions. The check we have does exactly that - it starts from annotated plugin interfaces and traverse all affected types.

Allowing wide use of @InternalApi unrestrictedly completely defeats the purpose.

[gbbafna]

Why do we need to restrict it to constructors ? In above PR , all the members , getters etc are not supposed to be accessed from outside ?

I do agree that we shouldn't allow wide use of @InternalApi , but the usecase we saw above won't get solved with that .

[reta]

I do agree that we shouldn't allow wide use of @InternalApi , but the usecase we saw above won't get solved with that .

This is the reason, it is impossible to restrict once open wide

[gbbafna]

Got it . We can always start with support constructors the @internalapi on to highlight the fact that instantiation of that particular type is not supposed to be done by outside of the OpenSearch. Then we can see how it is shaping for us .

[peternied]

[Triage - attendees 1 2 3 4 5 6 7]
@gbbafna Thanks for creating this issue; however, it isn't being accepted due to not having a clear reproduction and expectations. Please feel free to open a new issue after addressing the reason.

[gbbafna]

Reopening this as we faced the exact same issue in #13663 . see draft PR

RemoteStorePathStrategy is an internal API and is not supposed by to used/extended by plugins . However we can't mark it internal api .

error: The element org.opensearch.index.remote.RemoteStorePathStrategy is part of the public APIs but is marked as @InternalApi (referenced by org.opensearch.index.IndexSettings) 

error: The element org.opensearch.index.remote.RemoteStorePathStrategy is part of the public APIs but is marked as @InternalApi (referenced by org.opensearch.index.snapshots.blobstore.RemoteStoreShardShallowCopySnapshot) 

RemoteStorePathStrategy's constructor has to be public as RemoteStoreShardShallowCopySnapshot needs to create it .