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

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.