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

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.