avalon-phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Contents of phoenix-client.jar
Date Sat, 07 Sep 2002 11:00:45 GMT
I just raised a similar thing in a mail now, good, it seems we have a 
similar need :-)  (going to eat now)


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'?
> 
>    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).


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:avalon-phoenix-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-phoenix-dev-help@jakarta.apache.org>


Mime
View raw message