Version 9

    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