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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
