Spec re-organization/update proposal...

[Bryan Atsatt]

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.

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.


If the reasoning behind these proposals is not sufficiently clear to
everyone, I'll be happy to elaborate.

// Bryan

[Stanley M. Ho]

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

[Andy Piper]

Agreed

andy

At 01:47 18/04/2008, 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.
>
>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.
>
>
>If the reasoning behind these proposals is not sufficiently clear to
>everyone, I'll be happy to elaborate.
>
>// Bryan

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

[Andy Piper]

At 02:50 18/04/2008, Stanley M. Ho wrote:
>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).

Well, except of course that OSGi 4.1 is already a JSR courtesy of JSR
291. That puts it in a class of its own IMO.

andy



Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

[Richard S. Hall]

Sounds good to me.

-> richard

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.
>
> 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.
>
>
> If the reasoning behind these proposals is not sufficiently clear to
> everyone, I'll be happy to elaborate.
>
> // Bryan

[Strigun, Vladimir A]

agreed


-----Original Message-----
From: Java Community Process JSR #277 Expert List
[mailto:JSR-277-EG@...] On Behalf Of Bryan Atsatt
Sent: Friday, April 18, 2008 4:48 AM
To: JSR-277-EG@...
Subject: Spec re-organization/update proposal...

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.

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.


If the reasoning behind these proposals is not sufficiently clear to
everyone, I'll be happy to elaborate.

// Bryan

--------------------------------------------------------------------
Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.