[jbosscache-dev] Jarring jars

Scott Marlow scott.marlow.opensource at gmail.com
Fri Feb 16 11:12:58 EST 2007


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/.
>
We would need to be careful not to rename the Java package name for any 
classes that show up in the parameter list of any exposed APIs. 

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




More information about the jbosscache-dev mailing list