Quoting James Strachan <[EMAIL PROTECTED]>: > Given that the current xerces jar is 1.6Mb, having a single Jelly jar of > around 400-500k doesn't seem so bad. I guess splitting some of the bigger > optional libraries off (like JellySwing) might help keep the size down a > bit. What are others thoughts on this? Are big jars a problem these days?
It's not so much the fact the jar is big, but that it's likely to change more often, the more projects that are in it. If I'm developing code that uses Jelly core, and just one or two other libraries, I like to know when I need to upgrade. For personal projects it's not a big deal, but if you're on a large corporate project getting close to release date, the management tend to be very nervous about regular version changes. I think it'll make releasing updates to sub-projects easier as well, as they can be released independently. So my vote's for a core Jelly (+ core, xml, util, dynabean + bean) and separate JARs for the other projects. I suppose you could always release a bundle-jar on a regular basis, with the core and all known (recommended?) sup-projects for those who just want an easy life. > Ultimately, what would totally rock would be if Jelly could use a Maven/JJAR > mechanism that each Jelly library could be downloaded as its required along > with any dependent jars required kinda like how Maven plugins work. Though > thats a significant bit of work :-) Yep. Though I can see I might have some work cut out justifying auto-updates in a production environment! James -- To unsubscribe, e-mail: <mailto:commons-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:commons-dev-help@;jakarta.apache.org>
