commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert" <>
Subject RE: [jelly] build and distribution issues (was Re: [Latka][Proposal] Make Jelly a required dependency?)
Date Fri, 18 Oct 2002 15:40:48 GMT
I would agree with James on this one as well. It seems similar to what
Ant does, have the core stuff and the optional stuff. While I will
probably use the whole thing, it would still simplify upgrades.

- Robert

-----Original Message-----
From: James Elson [] 
Sent: Friday, October 18, 2002 9:39 AM
To: Jakarta Commons Developers List
Subject: Re: [jelly] build and distribution issues (was Re:
[Latka][Proposal] Make Jelly a required dependency?)

Quoting James Strachan <>:

> Given that the current xerces jar is 1.6Mb, having a single Jelly jar
> around 400-500k doesn't seem so bad. I guess splitting some of the
> optional libraries off (like JellySwing) might help keep the size down
> bit. What are others thoughts on this? Are big jars a problem these

It's not so much the fact the jar is big, but that it's likely to change
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
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
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
those who just want an easy life.

> Ultimately, what would totally rock would be if Jelly could use a
> mechanism that each Jelly library could be downloaded as its required
> with any dependent jars required kinda like how Maven plugins work.
> 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!


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message