Return-Path: Delivered-To: apmail-jakarta-avalon-phoenix-dev-archive@apache.org Received: (qmail 14520 invoked from network); 7 Sep 2002 10:04:10 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 7 Sep 2002 10:04:10 -0000 Received: (qmail 1429 invoked by uid 97); 7 Sep 2002 10:04:55 -0000 Delivered-To: qmlist-jakarta-archive-avalon-phoenix-dev@jakarta.apache.org Received: (qmail 1413 invoked by uid 97); 7 Sep 2002 10:04:55 -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 1401 invoked by uid 98); 7 Sep 2002 10:04:54 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3D79CF03.3080401@yahoo.com> Date: Sat, 07 Sep 2002 11:03:47 +0100 From: Paul Hammant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon-Phoenix Developers List Subject: Contents of phoenix-client.jar Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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'? org\apache\avalon\phoenix\AbstractBlock.class org\apache\avalon\phoenix\ApplicationEvent.class org\apache\avalon\phoenix\ApplicationListener.class org\apache\avalon\phoenix\Block.class org\apache\avalon\phoenix\BlockContext.class org\apache\avalon\phoenix\BlockEvent.class org\apache\avalon\phoenix\BlockListener.class org\apache\avalon\phoenix\Constants.class org\apache\avalon\phoenix\metadata\BlockListenerMetaData.class org\apache\avalon\phoenix\metadata\BlockMetaData.class org\apache\avalon\phoenix\metadata\DependencyMetaData.class org\apache\avalon\phoenix\metadata\SarMetaData.class org\apache\avalon\phoenix\metainfo\BlockDescriptor.class org\apache\avalon\phoenix\metainfo\BlockInfo.class org\apache\avalon\phoenix\metainfo\DependencyDescriptor.class org\apache\avalon\phoenix\metainfo\ServiceDescriptor.class org\apache\avalon\phoenix\tools\assembly.dtd org\apache\avalon\phoenix\tools\blockinfo.dtd org\apache\avalon\phoenix\tools\mxinfo.dtd org\apache\avalon\phoenix\tools\assembler\Assembler.class org\apache\avalon\phoenix\tools\assembler\AssemblyException.class org\apache\avalon\phoenix\tools\assembler\Resources.properties org\apache\avalon\phoenix\tools\configuration\ConfigurationBuilder.class org\apache\avalon\phoenix\tools\configuration\DTDInfo.class org\apache\avalon\phoenix\tools\configuration\DTDResolver.class org\apache\avalon\phoenix\tools\infobuilder\BlockInfoBuilder.class org\apache\avalon\phoenix\tools\infobuilder\Resources.properties org\apache\avalon\phoenix\tools\tasks\Sar.class org\apache\avalon\phoenix\tools\verifier\Resources.properties org\apache\avalon\phoenix\tools\verifier\SarVerifier.class org\apache\avalon\phoenix\tools\xdoclet\blockinfo.xdt org\apache\avalon\phoenix\tools\xdoclet\BlockInfoSubTask.class org\apache\avalon\phoenix\tools\xdoclet\manifest.xdt org\apache\avalon\phoenix\tools\xdoclet\ManifestSubTask.class org\apache\avalon\phoenix\tools\xdoclet\mxinfo.xdt org\apache\avalon\phoenix\tools\xdoclet\MxInfoSubTask.class org\apache\avalon\phoenix\tools\xdoclet\PhoenixXDoclet.class It maybe that a split into two is appropriate. If there are more than a couple of classes not part of the API, it may be a good peacekeeping measure to split a second jar out... Those that are new to the world of Avalon enterprise containers, should remember that we are not in a rash design stage. We have a product that has been in use for some years, it would be nice to be honorable to that package (Phoenix). Regards, - Paul -- To unsubscribe, e-mail: For additional commands, e-mail: