[jbosscache-dev] Let's make 3.0 backwards compatible

[Manik Surtani]

On 20 Aug 2008, at 16:40, Jason T. Greene wrote:

> Manik Surtani wrote:
>> On 19 Aug 2008, at 20:33, Jason T. Greene wrote:
>>> Brian Stansberry wrote:
>>>> Manik Surtani wrote:
>>>>>> This is one of the main things I want to talk about when we  
>>>>>> have our AS meeting in Neuchatel the week before the Brno  
>>>>>> meeting. The AS needs a general solution to this problem.
>>>>>
>>>>> Jarjar.  :-)  I really think it would work.  It would make  
>>>>> upgrading individual jars hard and may bloat the overall  
>>>>> download size a bit, bit it nicely isolates things such that  
>>>>> different subsystems may be tied to different versions of  
>>>>> dependent libraries.  Actually, upgrading needn't be that hard -  
>>>>> e.g., all clustering code could be encapsulated in a single  
>>>>> jboss-as-clustering-5.0.jar which includes jarjar'd versions of  
>>>>> JBC, JGroups, other deps, as well as AS Clustering classes.   
>>>>> Upgrading could involve a new jboss-as-clustering-5.1.jar which  
>>>>> may include a new release of JBC, etc., without affecting other  
>>>>> JBC users, whether they be end user apps or other subsystems.
>>>>>
>>>> We'll discuss this in Neuchatel.  This kind of thing requires buy- 
>>>> in from several projects, e.g. the hibernate integration is part  
>>>> of Hibernate; the SFSB integration is part of EJB3. Both of which  
>>>> are meant to work outside the AS (Hibernate for sure; EJB3 in as- 
>>>> yet-unrealized theory.)
>>>
>>> In the meantime, I think what we can do to solve the 4.2 issue, is  
>>> to provide the community with an ant task that would use jarjar to  
>>> create a fully isolated jar for jboss cache and all of its  
>>> dependencies.
>> I think the best approach would be a jbosscache-core-compat module  
>> (on the same level as jbosscache-core) which consists of a Maven  
>> POM which depends on jbosscache-core, which just handles the  
>> package relocation and spits out jbosscache-core-compat.
>> Then another pair of modules - jbosscache-core-compat-1.x and  
>> jbosscache-core-compat-2.x - which depend on jbosscache-core-compat  
>> and provide interface bridges to 1.x or 2.x interfaces would do the  
>> trick.
>
> Doing a bridge would mean that the existing jboss cache would have  
> to be removed, which may or may not work with the AS clustering  
> code. It would also have to use a package modified version of  
> jgroups, since other modules depend on the version that is there.
>
> However, just giving them the ability to rename everything to some  
> safe package name would not interfere with anything. It's also less  
> work ;) It does require them to use a different package than the API  
> we publish though.

Ah, you mean using jarjar to create a specific version for *their*  
application.

Yeah, using a different package than the shipped API would make things  
tricky to move forward for them.  But yes, I agree it is a valid  
approach.  Perhaps for the AS 4.x thing like you said.

Then it is just a case of making the 3.x APIs 2.x compatible from the  
outset.  Then no need for bridges.  Need to think about this though.

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org