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

[Jason T. Greene]

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.

-- 
Jason T. Greene
JBoss, a division of Red Hat