Dear all, here are the paragraphs I want to add to the "Contributing to Infinispan" page in relation to the API, Commons, Core split. Comment please on clarity, grammar, spelling, etc API, Commons, Core In order to provide proper separation between public APIs, common utilities and the actual implementation of Infinispan, these are split into 3 modules: infinispan-api, infinispan-commons and infinispan-core. This separation also makes sure that modules, such as the remote clients, don't have to depend on infinispan-core and its transitive dependencies. The following paragraphs describe the role of each of these modules and give indication as to what goes where. API The infinispan-api module should only contain the public interfaces which can be used in any context (local, remote, etc). Ideally it should not contain any concrete classes, however this rule can be relaxed for small, self-contained classes which need to be referenced from the API interfaces. When promoting interfaces from infinispan-core to infinispan-api, please bear in mind the type of functionality that is being exposed: if something only makes sense for local mode and not for remote mode (e.g. eviction), then it should remain in infinispan-core. Commons The infinispan-commons module contains utility classes which can be reused across other modules. Classes in infinispan-commons should be self-contained and not pull in unnecessary dependencies. They should also make no reference to configuration aspects specific to a particular environment. Core The infinispan-core module contains the actual implementation used for local/embedded mode. When adding new functionality to the APIs, it is generally safe to start by putting them in infinispan-core and promoting them to infinispan-api only when it is deemed to do so and it makes sense across the various use-cases. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

> API > > The infinispan-api module should only contain the public interfaces which can be used in any context (local, remote, etc). Ideally it should not contain any concrete classes, however this rule can be relaxed for small, self-contained classes which need to be referenced from the API interfaces. When promoting interfaces from infinispan-core to infinispan-api, please bear in mind the type of functionality that is being exposed: if something only makes sense for local mode and not for remote mode (e.g. eviction), then it should remain in infinispan-core. Perhaps "Interfaces only. Concrete classes on a case-by-case basis, treated as exceptions, and only after discussion on this list.". Actually, *anything* that goes in this module should be only after discussion on this list. :-)