Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 94475 invoked from network); 7 Sep 2002 14:07:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Sep 2002 14:07:24 -0000 Received: (qmail 17877 invoked by uid 97); 7 Sep 2002 14:07:57 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 17861 invoked by uid 97); 7 Sep 2002 14:07:57 -0000 Mailing-List: contact avalon-phoenix-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon-Phoenix Developers List" Reply-To: "Avalon-Phoenix Developers List" Delivered-To: mailing list avalon-phoenix-dev@jakarta.apache.org Received: (qmail 17848 invoked by uid 98); 7 Sep 2002 14:07:56 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Subject: Re: Contents of phoenix-client.jar From: Leo Simons To: Avalon-Phoenix Developers List In-Reply-To: <200209072130.07421.peter@apache.org> References: <3D79CF03.3080401@yahoo.com> <200209072130.07421.peter@apache.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 07 Sep 2002 16:07:17 +0200 Message-Id: <1031407637.2072.87.camel@lsd.bdv51> Mime-Version: 1.0 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 2002-09-07 at 13:42, Peter Donald wrote: > On Sat, 7 Sep 2002 20:03, Paul Hammant wrote: > > Folks, > > > > We have recently agreed that enterprise containers seeking to host > > blocks should 1) include phoenix-client.jar and 2) provide a > > /implementation/ for the interfaces contained in that jar. Perhaps it > > is time to have an honest appraisal of the contents of > > phoenix-client.jar and see if there are any entries that are not part of > > the API. Here are the contents of the jar. Can anyone see any entries > > that are inappropriate for inclusion into this 'block API jar'? > > A lot of it is legacy. Constants.class is there because we mistakenly included > it ages ago and someone complained when I took it out. > Block/AbstractBlock/BlockListener are all deprecated. The metadata/info is > required because of listeners. > > Tools probably could have been removed but people said that they would prefer > that all the classes for developing clients be kept in one jar. I believe you > were one of those people actually ;) > > It will trim down when we move to new component model. I don't think there is > any need to change anything until then. +1 (though I have reservations with regards to "new component model" (need to see it before endorsing it ;)); I think the current jar has right size and content wrt backwards compatibility 'n stuff. cheers, Leo -- To unsubscribe, e-mail: For additional commands, e-mail: