|
All,
I have decided it is time for a new thread, as I am starting to
get lost in "Recent Edits".
Recently Bill Shannon, Ivar Grimstad, Steve Millidge and Scott
Stark had some comments on the interaction between the code first
approach and the specification process requirements. For the
record, I think Ivar's email is so spot-on we might want to add it
to the document as a use case to help elaborate on the
requirements.
Bill Shannon:
- ... we were previously expecting that a specification project
would manage the specification document, the source code for the
API classes, and the source code for the TCK. Assuming we need
special rules for specification projects, do we really want
those special rules to apply to the API and TCK, which after all
are just source code projects?
- ... The API classes are hard because they mix specification
with (varying amounts of) implementation. But none of the IP
issues for the spec apply to the TCK, right? Maybe the TCKs
should be in separate code projects that follow the normal EDP
rules?
- Proposed Resolution:
- The definition of a Specification Project should be refined
to recognize that the Specification Document and the TCK will
be done in separate Eclipse project managed under the same
PMC.
- Now that there is no single Reference Implementation, we
need to fix that in the definition as well.
Steve Millidge:
- I think is the root of my confusion the specification process
discussions seem to be pushing back towards the spec first
approach with Expert Groups etc.
- Proposed Resolution: If you have any specific
suggestions on how to improve the wording, please suggest or
comment on the document. Personally, I don't think that the spec
process is pushing back on code first at all. At some point you
still have to take IP from the code and turn it into a
Specification, and that's what we're working on. But I fully
admit that I'm perhaps too close to the wording, and will
happily take suggestions to make that clearer.
Scott Stark:
- ...this looks to be in conflict with the requirement that one
be able to create a clean room implementation from the spec
document due to the references to the JavaDoc produced from the
external API code.
- Proposed Resolution: I am not seeing this. Ivar makes
it clear that you end up with a formal specification document
and that other implementations would be expected to move to
reflect those updates.
HTH
|
