I like the idea, but messaging did a similar thing with their jboss-messaging-client.jar and customers wondered how to upgrade things like log4j.jar. Do we want to to provide both unpacked and packed jars? We need unpacked one for upgrading purpouses. Another option instead of packing JARs would be to provide different library folders for different environments: - Standalone Java 5 - Standalone Java 1.4 - AS 4.0.x Java 5 - AS 4.0.x Java 1.4 - AS 5.0 Java 5 - Websphere Java 1.4 This would have the benefit of telling customers what libraries they need for each situation providing good orientation to the customers. You could say that a 1.4.x release should not run in JBoss 5.0 and so, we do not provide a directory for "AS 5.0 Java 5" Customers always gonna have to compare the libraries in target environments with the ones in the JBossCache distro in case anything else apart from JBossCache needs upgrading. Thoughts? 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? > > Thoughts? > -- > Manik Surtani > > Lead, JBoss Cache > JBoss, a division of Red Hat > > Email: manik(a)jboss.org > Telephone: +44 7786 702 706 > MSN: manik(a)surtani.org > Yahoo/AIM/Skype: maniksurtani > > > > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev

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/.

> Thoughts? > -- > Manik Surtani > > Lead, JBoss Cache > JBoss, a division of Red Hat > > Email: manik(a)jboss.org > Telephone: +44 7786 702 706 > MSN: manik(a)surtani.org > Yahoo/AIM/Skype: maniksurtani > > > > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev >

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).

<SNIP />

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).