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.
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org