commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [Latka][Proposal] Make Jelly a required dependency?
Date Tue, 15 Oct 2002 16:12:06 GMT

James,

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.

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?
>
>James
>-------
>http://radio.weblogs.com/0112098/

--
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:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message