-
-
Notifications
You must be signed in to change notification settings - Fork 340
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
Properly export enums in public API #1039
Comments
Other thoughts. We could keep this for 4.0 and have the package name match the module name, though that seems like unnecessary import breakage. We could also duplicate those enums in the plugin module and map them to the backend enums. That's probably the nicest solution for users in the long run, but might be a pain to deal with and also requires 4.0 breakage. |
I have seen as common practice to have a |
@SUPERCILEX I can open a PR creating this module and moving this part as a non breaking change so you don't need to jump to 4 yet. Later rest of public APIs can be moved gradually. |
Can you try a type alias first and see what happens in Groovy? Lines 67 to 95 in 4273731
Lines 99 to 100 in 4273731
If it doesn't work, then I'm happy to accept a PR that creates an api module. |
Any more momentum on this? |
This method solved the problem. I don't think it's the right way, though. |
Ideally we can just use a type alias, but I don't think groovy will understand that. If the type alias doesn't work, we can pull resolution strategy and release status into their own module under the existing package name and export that.
The text was updated successfully, but these errors were encountered: