Skip to content
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

Move GuiceSlickProvider to an internal package #1384

Open
octonato opened this issue Jun 7, 2018 · 1 comment
Open

Move GuiceSlickProvider to an internal package #1384

octonato opened this issue Jun 7, 2018 · 1 comment
Labels

Comments

@octonato
Copy link
Member

octonato commented Jun 7, 2018

This PR #1360 exposed the fact that all Guice modules are got impacted by the MiMa checks while we should consider them internal API.

It also exposed that com.lightbend.lagom.javadsl.persistence.jdbc.GuiceSlickProvider is a public API. It's a Guice provider, thus only for internal wiring, and it provides the SlickProvider that itself is a private class.

I suggest that all Guice modules are moved to com.lightbend.lagom.internal (or a subpackage of it) and that the Provider become internal and private.

WDYT?
/cc @ignasi35 @TimMoore

@TimMoore
Copy link
Contributor

TimMoore commented Jun 8, 2018

It's intentional that the module classes are public, even though we don't expect people to have a binary dependency on them, they might use the names to enable or disable modules.

See @jroper's comment: #1360 (comment)

These modules are not designed to be used directly by users, they're only there so that users can explicitly disable them using play.modules.disabled.

Changing the package structure would break existing config, and it would mean that these don't appear in the Java API documentation, so people won't know how to disable them without reading the Lagom source code.

I agree though that GuiceSlickProvider should become internal.

@TimMoore TimMoore changed the title Move Guice Modules and Providers internal package Move GuiceSlickProvider to an internal package Jul 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants