[infinispan-dev] Infinispan public API

[Mircea Markus]

On 23 Mar 2010, at 14:33, Manik Surtani wrote:

> Mircea and I were chatting about the HotRod client that he is writing, and we agreed that the best approach as far as API is concerned is for RemoteCache to extend Cache, RemoteCacheManager to extend CacheManager, etc., to maintain familiarity with p2p-style interaction with Infinispan as well as some ease in switching between interaction styles.
> 
> One impact of this is that the HotRod client would then have a dependency on infinispan-core.  So the question is, is this OK?  Pulling in a large number of classes that won't really be used except for the super-interfaces?  
> 
> One alternative is to pull the public API interfaces out of infinispan-core into a very light infinispan-api module.  This way the HotRod client can just add a dependency on this jar, but it would mean infinispan-core has a dependency on this jar as well.  One side-effect benefit here is that public API will be very clearly defined.
another would be to include only the classes that are needed by the hot rod client in the hotrod client distribution.
Thinking some more on the core-api and core-impl spli, one would have to have both of them at all time in the classpath, which means that autocompletion tools in IDEs for e.g. would still pick classes from core-impl. Guess the best approach for this is to use OSGI (ifrc we have a jiea for this).
The advantage I see in having the core-api and core-impl split is for hot rod client not to take with it more than needed. But that might be solvable through a mvn assembly.  
> 
> Thoughts?
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev