Re: [jbosscache-dev] Jarring jars
Scott Marlow wrote:
Manik Surtani wrote:
> The list of jars JBoss Cache ships with is growing. And this is, as
> you can imagine, a PITA.
>
> * Core libs - commons-logging, jgroups, concurrent (needed by JGroups
> < 2.5), jboss-serialization, jboss-common-core
> * Pojocache libs - trove, jboss-aop, javassist, microcontainer jars (4
> jars here!!)
> * JDK1.4-compat distro: 4 extra jars here
> * Optional jars: c3p0 (DB connection pooling for standalone use),
> bdbje and jdbm for specific cache loaders.
>
> Looking at how Bill's packaged libs up for embedded EJB, he's got an
> ant task that jars up all the jars into a single file.
>
> <jar jarfile="UberJar.jar">
> <zipfileset file="jar1.jar" />
> <zipfileset file="jar2.jar" />
> ...
> </jar>
>
> What do you think? This way the JBoss Cache distro can ship with a
> minimal number of jars:
>
> * Core: jboss-cache.jar, jboss-cache-deps.jar
> * PojoCache: jboss-cache.jar, jboss-cache-deps.jar, pojo-cache-deps.jar
> * JDK1.4-compat: jboss-cache.jar, jboss-cache-deps-JDK14.jar
> * Optional jars
>
> What do you guys think of this approach? It may mean a replication of
> jars (you may already have commons-logging or jboss-serialization in
> your libs) but these jars are small and not a huge impact on size.
> What about wanting to swap out jars, e.g., JGroups?
>
+1 For this approach as it helps the "Java jar version hell" problem
that occurs when an application wants to use a different version of a
jar than various JBoss projects uses. I'm assuming that we would also
change the package name otherwise the "jar version hell" problem is not
solved.
This would make it difficult to swap in a new jgroups jar but I'm
assuming that we wouldn't jarjar the jgroups.jar.
In case anyone is not familiar with the jarjar ant task, this page talks
about it http://tonicsystems.com/products/jarjar/manual/.
Ugh. You're correct; if you don't obfuscate the packages, IMO bundling
the jars actually makes things worse, since it hides the class in an
unfamiliar package.
Obfuscating the packages sounds like a support nightmare. No longer can
users themselves easily see what's going on in 3rd party classes we call
into. Things like scoped usage of commons-logging may break as well.
I can't imagine obfuscated versions of org.jboss classes ever being
allowed into the AS. Probably not commons-logging or javassist either.
IMHO this needs to be solved by reducing the number of dependencies,
better documenting their use (i.e. when each jar is needed) and
compatibility, and better organizing them in the dist (i.e. segregate
jars required at runtime from optional ones and from ones only needed
during build or testing).
For proper AS build integration, the component-info.xml in
repository.jboss.com for a JBC release should include this kind of thing:
<import componentref="javassist">
<compatible version="3.3.0.GA"/>
<compatible version="3.4.GA"/>
</import>
Properly maintaining that element can drive the documentation of
compatibility.
Re: reducing dependencies, how about (for 2.0):
1) Standardize on JGroups 2.5 and chuck concurrent.jar.
2) Chuck JDK 1.4 compatibility, which IMHO is a lot of trouble for
little gain. Since AS 4.2 ships with 1.4.x, we're going to have to do
bug fixes on 1.4.x for a number of years. That makes it a semi-living
branch for those non-JBAS users who require JDK 1.4.
3) See if any of the PojoCache dependencies can be eliminated or reduced
to optional (e.g. microcontainer).
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com