Enforce api/internal package conventions

olim7t commented 4 years ago

Some of the package in the runtime module follow the driver API conventions:

com.datastax.oss.quarkus.runtime.api
com.datastax.oss.quarkus.runtime.internal

But that has not been applied consistently:

package config is directly under quarkus
packages graal, health and metrics are directly under runtime.
classes AbstractCassandraClientProducer and CassandraClientRecorder are directly under runtime.

Move types to their correct location, depending on what's an "official" API for application developers, vs what's an internal implementation detail. I think most should go to internal, except maybe the config classes and the health check, depending on how they're supposed to be used (?)

The deployment module is used at build time only, so it doesn't matter that much. But following what we did for mapper-processor I would suggest putting everything into internal.

quickstart and integration-tests don't matter.

┆Issue is synchronized with this Jira Task by Unito

adutra commented 4 years ago

@olim7t there was already #27 open for that. However I think we first need to assess whether or not it makes sense to use the api/internal distinction for this project. We don't have formalized contribution guidelines yet, so that's open for debate. We also have #34 to add a CONTRIBUTING file.

tomekl007 commented 4 years ago

closed because this is a duplicate of https://github.com/datastax/cassandra-quarkus/issues/27

datastax / cassandra-quarkus

Enforce api/internal package conventions #62