commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: [Latka][Proposal] Make Jelly a required dependency?
Date Tue, 15 Oct 2002 17:01:46 GMT
Ceki Gülcü wrote:

> My suggestion would be to be patient and let Jelly mature a little
> more, especially with regards to documentation. When you feel that you
> are ready, then you can choose to go with commons or directly
> jakarta. Being in a sandbox has advantages because your project can
> grow slowly without user pressure. It's kind of like adolescence, when you
> are in it you can't wait to get out, but once out you cannot go back.

Being is sandbox has the disadvantage that you can't have releases
( acording to the current rules for commons ). I think it would be usefull
to have milestones and betas, so more people can use the code.

Moving to commons would also open the door to more commiters to get
involved and eventually use it in other projects. Of course, that's 
something you may want or not - it'll start raising questions about 
backward compatibility and stability, and you may loose some control.

Getting out of sandbox is usually a signal that things are getting serious 


> At 11:38 15.10.2002 +0100, James Strachan wrote:
>>I agree with both your and Craig's opinions on the matter. I'm finding it
>>hard to decide either way. I think on balance I'd kinda rather keep around
>>the Commons too I think; though I was a bit unsure if Jelly was becoming a
>>bit too 'framework'-ish for commons. The core of Jelly should be small and
>>embeddable and so fits the idea of a commons component. Though it was the
>>various plugin libraries which are kinda like sub-projects that made me
>>think Jelly maybe should maybe be a top level project with a common-core
>>and many independent sub-projects. Hopefully the Jelly build process will
>>get sorted out soon so that it will become much more modular so its easier
>>for folks to just embed what they need.
>>So should Jelly stay in commons or be a top level project? I don't really
>>feel strong enough either way really, so I'm tempted to err on the side of
>>caution and recommend it stays in commons but maybe, like httpclient, have
>>a seperate mail lists to avoid folks not interested in Jelly getting
>>bombarded with mail.
>>I'll call a vote to promote Jelly to commons proper shortly. If we decide
>>later on that Jelly should move out of commons to a top level project we
>>can cross that bridge when we come to it. How's that sound?
> --
> Ceki
> TCP implementations will follow a general principle of robustness: be
> conservative in what you do, be liberal in what you accept from
> others. -- Jon Postel, RFC 793


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

View raw message