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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
