Open SUPERCILEX opened 2 years ago
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 -api
module (kotlin and android Gradle plugins for example), maybe that approach will scale better.
@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? https://github.com/Triple-T/gradle-play-publisher/blob/4273731c8126cdbf071300882718ec2ae12f3e3c/play/plugin/src/test/kotlin/com/github/triplet/gradle/play/PlayPublisherPluginIntegrationTest.kt#L67-L95. You need to remove these imports: https://github.com/Triple-T/gradle-play-publisher/blob/4273731c8126cdbf071300882718ec2ae12f3e3c/play/plugin/src/test/kotlin/com/github/triplet/gradle/play/helpers/IntegrationTestBase.kt#L99-L100
If it doesn't work, then I'm happy to accept a PR that creates an api module.
Any more momentum on this?
ResolutionStrategy.AUTO
cannot be accessed in KTS build files.
This method solved the problem. I don't think it's the right way, though. https://github.com/Triple-T/gradle-play-publisher/issues/885#issuecomment-800204441
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.