Hi Bryan,
Bryan Atsatt wrote:
I propose that we re-organize and update the next draft of the spec to
achieve the following:
1. Clearly identify and separate the two main elements of the spec:
a. Framework (i.e. api/spi)
b. Default implementation (i.e. .jam distribution format, tools,
usage examples, etc.)
2. Ensure that the framework is the primary focus of the spec,
identifying it as the means by which any implementation integrates with
the SE compiler and runtime.
3. Clarify that any implementation will benefit from the integration
story provided by the framework (I describe four concrete benefits in
http://atsatt.blogspot.com/2008/04/jsr-277-could-be-great-for-osgi.html).
4. Clarify the rationale for the existence of a new implementation.
Agreed on all four points.
5. Recognize the importance of building a second implementation to
validate the framework design.
6. Recognize OSGi as the right choice for that second implementation:
a. A formal JCP adopted module standard.
b. Wide market adoption.
JSR 277 certainly wants to enable multiple implementations of the
Repository and ModuleDefinition APIs, especially by OSGi containers.
It would be unusual for a normative spec to mention particular
implementations (except the default implementation). However, we are
happy to mention OSGi in a non-normative section that discusses the
benefits of integration between module systems.
- Stanley
