[infinispan-dev] Contributing to Infinispan: API, Commons, Core

[Galder Zamarreño]

Tristan, thanks for writing this up and clarifying this :)

Looks good to me.

Cheers,

On Nov 3, 2011, at 8:37 AM, Tristan Tarrant wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache