Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 77910 invoked from network); 15 Oct 2002 16:12:22 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 15 Oct 2002 16:12:22 -0000 Received: (qmail 13032 invoked by uid 97); 15 Oct 2002 16:13:05 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 12829 invoked by uid 97); 15 Oct 2002 16:13:03 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 12637 invoked by uid 98); 15 Oct 2002 16:13:02 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-Id: <5.1.0.14.0.20021015180141.020e2360@mail.qos.ch> X-Sender: ceki@mail.qos.ch X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 15 Oct 2002 18:12:06 +0200 To: "Jakarta Commons Developers List" From: Ceki =?iso-8859-1?Q?G=FClc=FC?= Subject: Re: [Latka][Proposal] Make Jelly a required dependency? In-Reply-To: <010601c27436$fb080ce0$3565a8c0@spiritsoft.com> References: <3DAA7BD2.8080409@apache.org> <018601c27386$4b07a7c0$3565a8c0@spiritsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: For additional commands, e-mail: