Packages

One module should have a single main package, its code base. Any main API goes into the module's main package. There can be any number of subpackages, which can again be API packages. For any API package, some special subpackages may be used to improve consistency

• support - API-supporting API. Provides optional implementations of interfaces in the main API from support/... Support classes should not be used by the API itself.

• util - also API, but provides utilities for support, for the API itself or for users. Classes can be used by any other packages.

• internal - Private API implementations details

• impl - Like internal

Identification of Modules

Identification of (API) modules should be (TBC):

• groupId - should be the fully qualified main package parent name

• artifactId - should be the main package name

If service provider or other implementation modules are separated from API modules (TBC): 

• groupId - should be the fully qualified API package parent name

• artifactId - should be the API package name + "-" + service/impl. name

Requirements for API packages

• All enums, annotations, interfaces, classes shall be fully Java-doced.

• Ideally, it should have a package-info.java which describes the API's purpose, its use cases and provides example usages.

• Make sure your API aggrees with the principles of high quality OO programming (least knowledge/interface segregation, loose coupling/dependency inversion, open-close/Liskov's Substitution, single responsibility), applies and exposes OO design patterns, and feels natural to use.