Berin Loritsch wrote:
Stephen McConnell wrote:
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.
How about this:
* Let's start with what we have.
* Let's start with the .spi subpackage with the interfaces, but no separate jar.
* Let's get that stable and working and at least 90% code coverage.
* After this point we start fitting the current containers to use the API
(Fortress/Phoenix at least)
* When we actually need to beef up the SPI portion, we do that then.
The critical thing at this time is getting the Meta info and using the API.
Users of the Meta info API are:
* The Containers * The meta-info plugin * (Future) Container Extensions
As we get a better feel what is beneficial for Container Extension writers,
we can concentrate on separating the API and SPI. That can only *really*
happen when we have some extensions written.
Does that sound like a workable plan?
Actually I prefer doing the seperation now. When you start managing classloaders the seperation becomes very important and this will have a direct impact on container side extensions. I can take care of it if you like - its just a few minutes effort.
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]
