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).
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
