[jbosscache-dev] Jarring jars

[Galder Zamarreno]

Taking this a bit further, we could provide jarjars for standalone 
environments where they make mostly sense.

And the results of which libraries needed in AS/WS/WL would be the 
result of integration tests run against them....

i know i'm dreaming but wouldn't it be good?

Galder Zamarreno wrote:
> 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 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
> 
> 


-- 
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat