Btw, just tried this approach for the cache migration stuff.
In case someone has a go, it's:
<jar jarfile="UberJar.jar">
<zipfileset src="jar1.jar" />
<zipfileset src="jar2.jar" />
...
</jar>
instead of
<jar jarfile="UberJar.jar">
<zipfileset file="jar1.jar" />
<zipfileset file="jar2.jar" />
...
</jar>
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
--
Galder ZamarreƱo
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat