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

[Brian Stansberry]

Manik Surtani wrote:
> 
> On 20 Aug 2008, at 04:28, Bela Ban wrote:
> 
>> I added an item to our agenda for Brno, so we can discuss it there (on 
>> FRI, but this will get shifted around anyway)
> 
> Hmm, re: 3.x, I think we need to move a bit quicker than that.  I'm 
> holding back 3.0.Beta1 until we decide on this approach, since it will 
> affect whether:
> 
> 1.  I revert to JBC 2.x interfaces
> 2.  move 3.x interfaces to a new package
> 3.  stick with new 3.x interfaces and rely on an adapter package.
>
> Thoughts?  Anyone want to take a vote on this?  :-)

Thoughts, not vote.

#2 I've gotta figure having 2 interfaces that are mostly equivalent 
would have to cause problems.

#3: AIUI, that means creating a jarjar'd 3.x and an adapter jar that 
exposes the 2.x API. Pro: end user apps have a stable API between minor 
AS releases. Con: Hibernate and/or EJB3 integration is likely stuck 
using 2.x APIs/the adapter, unless those projects are willing to support 
and integration module that uses the jarjar'd 3.x packages. TBD, after 
CR2 is out, since CR2 is near at hand and is my focus.

#1, I don't know how much that screws you up.

> 
> Manik
> 
> 
> 
> 
>>
>>
>> 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.
>>>
>>
>> -- 
>> Bela Ban
>> Lead JGroups / Clustering Team
>> JBoss - a division of Red Hat
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
> 
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
> 
> 
> 
> 
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com