 |
How the OSS/J APIs are bundled and released
When an API is ready to be submitted to the JCP for Final approval, the Spec Lead will send the components of the API to the JCP Proxy, Vincent Perrot. These components are:
- API specifications bundle
- Reference Implementations bundle
- TCK bundle
- licenses bundle
- questionnaire for qualified products
Specifications, RIs, TCK, and licenses bundles are described here below. As for the Questionnaire, this is used to certify products that use the API as clients. The current template for the questionnaire is available at the 'OSS/J All' TM Forum CWS at OSS/J Team/ APIs/ Questionnaires for Qualified Products/ OSSJ-XYZ-API-Questionnaire-1.5.1.txt.
The JCP Proxy will check the validity of the five API components and then:
- submit the first 4 components to the JCP to start the approval process
- upload all 5 components in a specific 'OSS/J All' CWS (OSS/J Team/ APIs/ API name - JSR number/ API version) previously created by TM Forum IT. TM Forum will then set up the API download page (http://www.tmforum.org/ossj/downloads/jsr number) that is needed by the JCP
 Important Note about Licenses:
In order to keep the license texts harmonized between all the JSRs, all the companies and all the bundles, TM Forum Program Manager for OSSJ and OSS Common JSR spec leader are maintaining and sending Licenses to the other Specification Leaders. To get update, or to simply obtain the Licenses for the Spec, Ri or TCK of your JSR please send e-mail to Antonio Plutino and Vincent Perrot.
No change shall be done in the sent License Text.
Preparing the API bundles
All OSS/J bundles are archived and distributed from the TM Forum web site.
The chosen format for all bundles is zip. The zip file shall contain a relative root directory using the same name as the bundle name.
The detailed file naming convention that applies to internal OSSJ document is described PRD-PROC-NAMING.u.v.html.
The general rules applied to zip name is:
- The prefix is the API name (as register in jcp.org site) without the "API" at the end, e.g. oss_common or fault_management
- The second field is the version number. Draft version uses "0" as major version number. The final bundles uses "1.0" as version number.
- The third field, valid only for specification bundle, is the JCP stage using "cr" for Community Review, "pd" for Public Draft, "pfd" Proposed Final Draft, "fr" Final Release, and "mrel" Maintenance Release.
- The type of the bundle using "spec" for Specification, "src-ri" for Reference implementation source and binary, and "tck" for Technology Compatibility Kit.
All documents included in a bundle must follow the OSS/J naming convention.
Listed below are examples of OSS through Java bundles.
Example using OSS Common API bundle names:
| Early Draft Review of the Specification | oss_common-0_5-edr-spec.zip |
| Public Draft of the Specification | oss_common-0_6-pd-spec.zip |
| Proposed final Draft of the Specification | oss_common -0_7-pfd-spec.zip |
| Final Specification | oss_common-1_0-fr-spec.zip |
| Maintenance Specification | oss_common-1_1-mr-spec.zip |
| Maintenance Specification X (X and Y may be different) | oss_common-1_Y-mrX-spec.zip |
| Final Reference Implementation | oss_common-1_0-src-ri.zip |
| Final TCK | oss_common-1_0-tck.zip |
| Final TCK src | oss_common-1_0-src-tck.zip |
Prefix used for other OSS/J bundles:
| 89 | OSS Service Activation API | oss_service_activation |
| 90 | OSS Trouble Ticket API | oss_trouble_ticket |
| 91 | OSS Quality of Service API | oss_quality_of_service |
| 130 | OSS Billing Mediation API | oss_billing_mediation |
| 142 | OSS Inventory API | oss_inventory |
| 144 | OSS Common API | oss_common |
| 210 | OSS Service Quality Management API | oss_service_quality_management |
| 251 | Pricing API | pricing |
| 254 | OSS dicovery API | discovery_control |
| 263 | Fault Management API | fault_management |
| 264 | Order Management API | order_management |
| 285 | Performance Management API | performance_management |
Note: to the postfix Add "_jvt" for the Java Value profile Reference Implementation and "_xvt" for the XML over JMS profile.
For example:
- oss_billing_mediation_jvt-1_1-src-ri.zip bundle that contains the src and binary code of the Java Value Type integration profile of reference Implemenattion of the OSS IP Billing API
- oss_billing_mediation_xvt-1_1-src-ri.zip bundle that contains the src and binary code of the XML/JMS Value Type integration profile of reference Implemenattion of the OSS IP Billing API
Note: to the postfix Add "_j2eesdk" (or "_javaeesdk") when the bundle deploy on a specific application server.
For example:
- oss_common_j2eesdk-1_1-src-ri.zip bundle that contains the src and binary code of the Java Value Type integration profile of reference Implemenattion of the OSS Common API.
- oss_common_javaeesdk-1_5-src-ri.zip bundle that contains the src and binary code of the OSS Common API RI v 1.5.
What to do Once the JSR final?
- Put the javadoc on-line under the public java.net project. For that create a directory under www named "javadocs/1.0" (1.0 or use the appropriated version number). Then copy/past all the generated javadoc (from where the index.html is) into it and CVS check in all the new created files and structures. The javadoc will then be on line at the URL: http://jsrXXX-public.dev.java.net/nonav/javadocs/1.0.
- Send the PART4 and PART5 zips of the spec containsing the XML schemas and the WSDL to the OSSJ TM Forum representative to get them under the http://ossj.org/xml or http://ossj.org/wsdl.
|