Berin Loritsch wrote:
Stephen McConnell wrote:
In this *special* case, I would be ok with the following structure:
meta-api <--- The set of exceptions and serializable descriptors that make up the meta-info layer (currently called meta-spi)
meta-spi <--- The set of container-side interfaces that define the system (e.g. builder and writer interfaces) - content is currently mixed under the impl package.
meta-impl <-- The implementation of the SPI (as as with the removal of the builder and writer interfaces).
Cheers, Steve.
:) I really hope we aren't going to have as many different ways of persisting the meta info as there are containers.
That said, we may change how we persist the information later. This separation just may come in handy in that case--esp. when we want to test our compatibility layers.
Another question:
In most Java APIs where there is both the client and service provider (like JCE) the separation was done at the Java package level. For example:
org.apache.avalon.meta --> typical API org.apache.avalon.meta.spi --> SPI specific classes
This is the way JCE and JNDI are both organised. All users of the software are provided with the API and SPI all in the same distributable.
Should we mimic this approach?
It seems of little value to me to have the SPI in a separate
JAR, although of great value to be able to plug in implementations
(so that Fortress can work with its older version of the meta
persistence).
With just the meta-info, the number of spi interfaces is rather small. I can imagine the SPI package growing to be more significant with the progressive evolution to include meta-data directives and meta-model interfaces. Given that this is an overhead for container developers and zero impact on users, I would keep the SPI seperate from the API.
Cheers, Steve.
--
Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net
Sent via James running under Merlin as an NT service. http://avalon.apache.org/sandbox/merlin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
