Infinispan Core Library
Currently (5.x) the Infinispan library is packaged as a JAR (infinispan-core) which includes all of the APIs, utility functions and some SPIs (FileCacheStore) and depends on: jboss-logging, jgroups, jboss-staxmapper, jboss-marshalling, jboss-marshalling-river, jboss-transaction-api (javax.transaction)
The monolithic approach causes the following issues:
- No clean separation between public APIs/SPIs and the library, requiring, for example the Hot Rod Client to pull in infinispan-core and all of its dependencies
- The above also applies to Utility/Common functioniality (e.g. org.infinispan.util)
- Too many dependencies for the local-only use case. JGroups and Marshalling should be optional dependencies if possible. Think about the Hibernate 2LC use-case.
- We cannot use the current infinispan-parent as a BOM for dependent projects, since it also acts as both a parent POM (i.e. it defines build-related configuration and dependency version information). This currently means that projects which cannot inherit from infinispan-parent (e.g. Infinispan Server) can however import the proper dependencies versions.
- Our current API contract for Caches is based on the ConcurrentMap interface (which is not ideal wrt some semantics. JCache has done away with that). We also introduce a BasicCache interface on top of that as a poor attempt to homogenize additional API t for both local and remote use-cases, even though the remote implementation throws UnsupportedOperationException for many methods.
The proposal is to:
- limit the core dependencies to jboss-logging and javax.transaction. Staxmapper functionality can be incorporated in Infinispan itself, jgroups is only needed for clustering and jboss-marshalling-* only matters for clustering and store-as-binary (and we can break with a runtime exception in case code attempts to use this without the supporting library).
- optionally introduce an infinispan-api JAR which will contain only interfaces to public APIs and SPIs.
- introduce an infinispan-commons library with utility functions. We should use the maven-shade-plugin to fold/relocate these classes in infinispan-core and infinispan-hotrod-client so that we limit the number of artifact dependencies while eliminating source code duplication.
- move the clustering functionality to an additional JAR (infinispan-clustering) which will carry the JGroups and JBoss marshalling dependency (the latter is a hard dependency in this case, while it is an optional dependency in the local case).
- extract the dependency information of the core components from infinispan-parent to an infinispan-bom
- move all non-core modules outside the Infinispan repository. "API" modules should remain in the library repository, since they are closely tied to the library itself.
- Remove the BasicCache interface and leave local and remote cache APIs independent of each other, until we can standardize (e.g. on jcache).
Therefore the Infinispan library repository would contain:
- infinispan-bom: BOM of compile-level dependencies (required and optional), e.g. jgroups, jboss-logging, jboss-marshalling
- infinispan-parent: parent artifact which imports infinispan-bom and provides all other dependencies and plugin configuration (i.e. test deps, etc)
- infinispan-api: JAR with APIs and SPIs
- infinispan-commons: JAR with common utils (i.e. hashing functions, etc)
- infinispan-local: JAR for local functionality (depends on infinispan-api and infinispan-commons), includes FileCacheStore. Incorporate simplified staxmapper functionality in core (dmlloyd claims staxmapper should eventually disappear)
- infinispan-clustering: JAR for clustering and xsite replication functionality (depends on infinispan-local, jgroups, jboss-marshalling).
The proposal is also to create the following additional repositories to hold components which need to be moved out of the main Infinispan repository:
- infinispan-cachestores: jdbc, jdbm, bdbje, cassandra, hbase, jpa, mongodb
- infinispan-cdi
- infinispan-spring
- infinispan-demos (incorporate the quickstarts?)
Infinispan server is already in a separate repository, and it will become the home of the various protocols: server-core, server-hotrod, server-memcached, server-websocket, server-rest, hotrod-client, remote cachestore
Comments