[infinispan-dev] Infinispan public API

[Galder Zamarreno]

On Wed, 24 Mar 2010 13:53:46 +0100, Manik Surtani <manik at jboss.org> wrote:

>
> On 24 Mar 2010, at 10:29, Mircea Markus wrote:
>
>>
>> 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.
>
> The thought of hacking Maven assemblies any more than I'd need to gives  
> me the jitters!  :)

I don't like the idea of manipulating Maven assemblies either. I've done  
some small work with it and it's a royal PITA.

I don't think there's a immediate need to create a core-api module with  
just the interfaces. Core jar is around 1MB. I think clients can live with  
that without any problems. We can always change this at a later stage if  
we get enough feedback because we're not tied to a single packaging style.

Cheers,

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


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